it's possible with C language, use of  graphics libraries
for creating graphical interfaces?

Thank you

Regards

"Z.zen" <z.zen@outspam.scom> writes:
> it's possible with C language, use of  graphics libraries
> for creating graphical interfaces?

Certainly, but it requires the use of system-specific extensions;
the standard C language and library have no graphics support.

For details, ask in a newsgroup that deals with your system (or do a
bit of Googling).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Z.zen wrote:
> it's possible with C language, use of  graphics libraries
> for creating graphical interfaces?
> 
> Thank you
> 
> Regards
> 
> 
> 

Yes, for the details for the windows system read
Petzold's book. It is very easy to read, and starts
at the beginning


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

On Jun 24, 2:47=A0pm, jacob navia <ja...@nospam.org> wrote:
> Z.zen wrote:
> > it's possible with C language, use of =A0graphics libraries
> > for creating graphical interfaces?
>
> > Thank you
>
> > Regards
>
> Yes, for the details for the windows system read
> Petzold's book. It is very easy to read, and starts
> at the beginning
>

And for Unix, Linux, or Windows with Cygwin, you can
use the X, Xt, and Motif libraries.

--
Fred Kleinschmidt

jacob navia <jacob@nospam.org> writes:
> Z.zen wrote:
>> it's possible with C language, use of  graphics libraries
>> for creating graphical interfaces?
>
> Yes, for the details for the windows system read
> Petzold's book. It is very easy to read, and starts
> at the beginning

But be aware that what you learn will be largely inapplicable to
non-Windows systems.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

In article <4a429eec$0$17768$ba4acef3@news.orange.fr>,
jacob navia  <jacob@nospam.org> wrote:
>Z.zen wrote:
>> it's possible with C language, use of  graphics libraries
>> for creating graphical interfaces?
>> 
>> Thank you
>> 
>> Regards
>> 
>> 
>> 
>
>Yes, for the details for the windows system read
>Petzold's book. It is very easy to read, and starts
>at the beginning

Incidentally, on the subject of choice of compiler (*), I guess what it
boils down to is that if you are going to do Windows programming in a C
or C-like language (for you language purists out there), you might as
well get and use VC Express and/or C#, both of which are free from the
great evil empire.  Although it is possible to do it with Unix-like free
tools (mingw and/or Cygwin), doing so is basically just asking for pain.

(*) I guess this was actually in another thread, but really, they're all
the same.  Anything that mentions the "W" word gets the usual treatment
from the regs (off topic, blah, blah, blah), so it really doesn't
matter.

In article <lnprctp910.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
>jacob navia <jacob@nospam.org> writes:
>> Z.zen wrote:
>>> it's possible with C language, use of  graphics libraries
>>> for creating graphical interfaces?
>>
>> Yes, for the details for the windows system read
>> Petzold's book. It is very easy to read, and starts
>> at the beginning
>
>But be aware that what you learn will be largely inapplicable to
>non-Windows systems.

Yes, much as what you learn about life on planet Earth will be largely
inapplicable when you take up residence on some other planet.

Fred <fred.l.kleinschmidt@boeing.com> writes:

> On Jun 24, 2:47 pm, jacob navia <ja...@nospam.org> wrote:
>> Z.zen wrote:
>> > it's possible with C language, use of  graphics libraries
>> > for creating graphical interfaces?
>>
>> > Thank you
>>
>> > Regards
>>
>> Yes, for the details for the windows system read
>> Petzold's book. It is very easy to read, and starts
>> at the beginning
>>
>
> And for Unix, Linux, or Windows with Cygwin, you can
> use the X, Xt, and Motif libraries.
>
> --
> Fred Kleinschmidt

Yeah, if you want to write an app people will laugh at. Otherwise start
the hellish process of Gnome v KDE v ..... You get the idea.

Motif!

LOL.


-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

"Kenny McCormack" <gazelle@shell.xmission.com> wrote in message 
news:h1u96l$e88$2@news.xmission.com...
> In article <lnprctp910.fsf@nuthaus.mib.org>,
> Keith Thompson  <kst-u@mib.org> wrote:
>>jacob navia <jacob@nospam.org> writes:
>>> Z.zen wrote:
>>>> it's possible with C language, use of  graphics libraries
>>>> for creating graphical interfaces?
>>>
>>> Yes, for the details for the windows system read
>>> Petzold's book. It is very easy to read, and starts
>>> at the beginning
>>
>>But be aware that what you learn will be largely inapplicable to
>>non-Windows systems.
>
> Yes, much as what you learn about life on planet Earth will be largely
> inapplicable when you take up residence on some other planet.

What planet do you live on? 

"Kenny McCormack" <gazelle@shell.xmission.com> wrote in message 
news:h1u93u$e88$1@news.xmission.com...
> In article <4a429eec$0$17768$ba4acef3@news.orange.fr>,
> jacob navia  <jacob@nospam.org> wrote:
>>Z.zen wrote:
>>> it's possible with C language, use of  graphics libraries
>>> for creating graphical interfaces?
>>>
>>> Thank you
>>>
>>> Regards
>>>
>>>
>>>
>>
>>Yes, for the details for the windows system read
>>Petzold's book. It is very easy to read, and starts
>>at the beginning
>
> Incidentally, on the subject of choice of compiler (*), I guess what it
> boils down to is that if you are going to do Windows programming in a C
> or C-like language (for you language purists out there), you might as
> well get and use VC Express and/or C#, both of which are free from the
> great evil empire.  Although it is possible to do it with Unix-like free
> tools (mingw and/or Cygwin), doing so is basically just asking for pain.

Patents aside for a moment, isn't basic CLI is a "standard"? Well, use Mono:

http://www.mono-project.com

It ports standard CLI to Linux, Mac, BSD, others on the way.




> (*) I guess this was actually in another thread, but really, they're all
> the same.  Anything that mentions the "W" word gets the usual treatment
> from the regs (off topic, blah, blah, blah), so it really doesn't
> matter.
> 

In article <h1ur16$2na9$1@news.ett.com.ua>,
Chris M. Thomasson <no@spam.invalid> wrote:
....
>>>But be aware that what you learn will be largely inapplicable to
>>>non-Windows systems.
>>
>> Yes, much as what you learn about life on planet Earth will be largely
>> inapplicable when you take up residence on some other planet.
>
>What planet do you live on? 
>

Just like you and everyone who posts to this newsgroup, I live on Earth.
And I seriously doubt anyone who posts to CLC will ever leave planet
Earth.  So, knowledge that isn't applicable to live on planet Earth is
unlikely to be of any value.  If you get my drift...

"Chris M. Thomasson" <no@spam.invalid> writes:

> "Kenny McCormack" <gazelle@shell.xmission.com> wrote in message 
> news:h1u93u$e88$1@news.xmission.com...
>> In article <4a429eec$0$17768$ba4acef3@news.orange.fr>,
>> jacob navia  <jacob@nospam.org> wrote:
>>>Z.zen wrote:
>>>> it's possible with C language, use of  graphics libraries
>>>> for creating graphical interfaces?
>>>>
>>>> Thank you
>>>>
>>>> Regards
>>>>
>>>>
>>>>
>>>
>>>Yes, for the details for the windows system read
>>>Petzold's book. It is very easy to read, and starts
>>>at the beginning
>>
>> Incidentally, on the subject of choice of compiler (*), I guess what it
>> boils down to is that if you are going to do Windows programming in a C
>> or C-like language (for you language purists out there), you might as
>> well get and use VC Express and/or C#, both of which are free from the
>> great evil empire.  Although it is possible to do it with Unix-like free
>> tools (mingw and/or Cygwin), doing so is basically just asking for pain.
>
> Patents aside for a moment, isn't basic CLI is a "standard"? Well, use Mono:
>
> http://www.mono-project.com
>
> It ports standard CLI to Linux, Mac, BSD, others on the way.
>

What do you mean "it ports CLI to Linux" ? What do you mean by CLI here?

Almost no one uses Mono. Its totally unproven.

"Richard" <rgrdev_@gmail.com> wrote in message 
news:h1v4kn$mug$3@news.eternal-september.org...
> "Chris M. Thomasson" <no@spam.invalid> writes:
>
>> "Kenny McCormack" <gazelle@shell.xmission.com> wrote in message
>> news:h1u93u$e88$1@news.xmission.com...
>>> In article <4a429eec$0$17768$ba4acef3@news.orange.fr>,
>>> jacob navia  <jacob@nospam.org> wrote:
>>>>Z.zen wrote:
>>>>> it's possible with C language, use of  graphics libraries
>>>>> for creating graphical interfaces?
>>>>>
>>>>> Thank you
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>>>>
>>>>
>>>>Yes, for the details for the windows system read
>>>>Petzold's book. It is very easy to read, and starts
>>>>at the beginning
>>>
>>> Incidentally, on the subject of choice of compiler (*), I guess what it
>>> boils down to is that if you are going to do Windows programming in a C
>>> or C-like language (for you language purists out there), you might as
>>> well get and use VC Express and/or C#, both of which are free from the
>>> great evil empire.  Although it is possible to do it with Unix-like free
>>> tools (mingw and/or Cygwin), doing so is basically just asking for pain.
>>
>> Patents aside for a moment, isn't basic CLI is a "standard"? Well, use 
>> Mono:
>>
>> http://www.mono-project.com
>>
>> It ports standard CLI to Linux, Mac, BSD, others on the way.
>>
>
> What do you mean "it ports CLI to Linux" ? What do you mean by CLI here?

http://www.ecma-international.org/publications/standards/Ecma-335.htm



> Almost no one uses Mono. Its totally unproven.

http://www.mono-project.com/Companies_Using_Mono 

>
> What planet do you live on?

MS Windows, compilers: Djgpp and Mingw.



Ciao

"Chris M. Thomasson" <no@spam.invalid> writes:

> "Richard" <rgrdev_@gmail.com> wrote in message 
> news:h1v4kn$mug$3@news.eternal-september.org...
>> "Chris M. Thomasson" <no@spam.invalid> writes:
>>
>>> "Kenny McCormack" <gazelle@shell.xmission.com> wrote in message
>>> news:h1u93u$e88$1@news.xmission.com...
>>>> In article <4a429eec$0$17768$ba4acef3@news.orange.fr>,
>>>> jacob navia  <jacob@nospam.org> wrote:
>>>>>Z.zen wrote:
>>>>>> it's possible with C language, use of  graphics libraries
>>>>>> for creating graphical interfaces?
>>>>>>
>>>>>> Thank you
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>Yes, for the details for the windows system read
>>>>>Petzold's book. It is very easy to read, and starts
>>>>>at the beginning
>>>>
>>>> Incidentally, on the subject of choice of compiler (*), I guess what it
>>>> boils down to is that if you are going to do Windows programming in a C
>>>> or C-like language (for you language purists out there), you might as
>>>> well get and use VC Express and/or C#, both of which are free from the
>>>> great evil empire.  Although it is possible to do it with Unix-like free
>>>> tools (mingw and/or Cygwin), doing so is basically just asking for pain.
>>>
>>> Patents aside for a moment, isn't basic CLI is a "standard"? Well, use 
>>> Mono:
>>>
>>> http://www.mono-project.com
>>>
>>> It ports standard CLI to Linux, Mac, BSD, others on the way.
>>>
>>
>> What do you mean "it ports CLI to Linux" ? What do you mean by CLI here?
>
> http://www.ecma-international.org/publications/standards/Ecma-335.htm


You are seriously referencing this to a new programmer who wants to try
gui programming in C?

>
>
>
>> Almost no one uses Mono. Its totally unproven.
>
> http://www.mono-project.com/Companies_Using_Mono 
>
>

But in the real world .... this is mostly "under development".

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

Richard wrote:

> "Chris M. Thomasson" <no@spam.invalid> writes:
> 
>> "Richard" <rgrdev_@gmail.com> wrote in message
>> news:h1v4kn$mug$3@news.eternal-september.org...
>>> "Chris M. Thomasson" <no@spam.invalid> writes:
>>>> Patents aside for a moment, isn't basic CLI is a "standard"? Well, use
>>>> Mono:
>>>>
>>>> http://www.mono-project.com
>>>>
>>>> It ports standard CLI to Linux, Mac, BSD, others on the way.
>>>>
>>>
>>> What do you mean "it ports CLI to Linux" ? What do you mean by CLI here?
>>
>> http://www.ecma-international.org/publications/standards/Ecma-335.htm
> 
> You are seriously referencing this to a new programmer who wants to try
> gui programming in C?

No, he's saying what he means by "CLI". Different question.

-- 
"You're down as expendable. You don't get a weapon."    /Dark Lord of Derkholm/

Hewlett-Packard Limited registered office:                Cain Road, Bracknell,
registered no: 690597 England                                    Berks RG12 1HN

In article <h1vs0a$b5u$5@news.eternal-september.org>,
Richard  <rgrdev_@gmail.com> wrote:
....
>>> What do you mean "it ports CLI to Linux" ? What do you mean by CLI here?

Yes, a good question, that.

>> http://www.ecma-international.org/publications/standards/Ecma-335.htm

For the benefit of those of us who don't go to arbitrary links posted on
the Usenet, what the h*** is it?  20 words will do.

"Kenny McCormack" <gazelle@shell.xmission.com> wrote in message 
news:h201ot$j2s$1@news.xmission.com...
> In article <h1vs0a$b5u$5@news.eternal-september.org>,
> Richard  <rgrdev_@gmail.com> wrote:
> ...
>>>> What do you mean "it ports CLI to Linux" ? What do you mean by CLI 
>>>> here?
>
> Yes, a good question, that.
>
>>> http://www.ecma-international.org/publications/standards/Ecma-335.htm
>
> For the benefit of those of us who don't go to arbitrary links posted on
> the Usenet, what the h*** is it?  20 words will do.

CLI stands for `Common Language Infrastructure'. It was created by Microsoft 
and is standardized by the ECMA and is also approved by the ISO (ISO/IEC 
23271:2006). The Mono project created an implementation of the CLI that 
works on Windows, Linux, Mac, BSD.

C# is based on the CLI. You can write programs in C# and have them run on 
any platform with binary compatibility which has an implementation of the 
CLI. 

On 2009-06-25, Chris M. Thomasson <no@spam.invalid> wrote:
> CLI stands for `Common Language Infrastructure'. It was created by Microsoft 
> and is standardized by the ECMA and is also approved by the ISO (ISO/IEC 
> 23271:2006). The Mono project created an implementation of the CLI that 
> works on Windows, Linux, Mac, BSD.

I don't know of any C compiler targeted for the CLI; and, I don't know how
such a thing would work since the CIL is fundimentally based in object
technology. C++ != C.

> C# is based on the CLI. You can write programs in C# and have them run on 
> any platform with binary compatibility which has an implementation of the 
> CLI. 

C# != C.

Chris M. Thomasson wrote:
> "Kenny McCormack" <gazelle@shell.xmission.com> wrote in message
> news:h1u96l$e88$2@news.xmission.com...
> > In article <lnprctp910.fsf@nuthaus.mib.org>,
> > Keith Thompson  <kst-u@mib.org> wrote:
....
> >>But be aware that what you learn will be largely inapplicable to
> >>non-Windows systems.
> >
> > Yes, much as what you learn about life on planet Earth will be largely
> > inapplicable when you take up residence on some other planet.
>
> What planet do you live on?

Apparently some planet where the likelihood of compiling C programs
for non-Windows systems is comparable to the likelihood of leaving the
Earth. It's either a planet with much more advanced space travel than
we have, or several orders of magnitude fewer non-Windows platforms.

On 2009-06-24, Z.zen <z.zen@outspam.scom> wrote:
> it's possible with C language, use of  graphics libraries
> for creating graphical interfaces?

GTK is written in and designed to be used from C.  It is open source and it
is available for Windows and Unix platforms.

http://gtk.org

Somebody already mentioned Motif.  Lesstif is an open source
re-implementation:

http://lesstif.sourceforge.net/

Tim Harig wrote:
> On 2009-06-25, Chris M. Thomasson <no@spam.invalid> wrote:
> > CLI stands for `Common Language Infrastructure'. It was created by Microsoft
> > and is standardized by the ECMA and is also approved by the ISO (ISO/IEC
> > 23271:2006). The Mono project created an implementation of the CLI that
> > works on Windows, Linux, Mac, BSD.
>
> I don't know of any C compiler targeted for the CLI; and, I don't know how
> such a thing would work since the CIL is fundimentally based in object
> technology. C++ != C.

I'm not sure what you're suggesting by that last comment. Almost every
feature of C90, and (in the latest C++ standard, several of the new
features in C99) is also a feature of C++. If there's any feature of C
that can't be implemented in CLI, it seems to me that the
corresponding C++ feature would also not be implementable.

On 2009-06-25, jameskuyper <jameskuyper@verizon.net> wrote:
> Tim Harig wrote:
>> I don't know of any C compiler targeted for the CLI; and, I don't know how
>> such a thing would work since the CIL is fundimentally based in object
>> technology. C++ != C.
>
> I'm not sure what you're suggesting by that last comment. Almost every
> feature of C90, and (in the latest C++ standard, several of the new
> features in C99) is also a feature of C++. If there's any feature of C
> that can't be implemented in CLI, it seems to me that the
> corresponding C++ feature would also not be implementable.

Yes, seeing as C++ was origionally a superset, it is generally possible to
implement C from inside of C++ code.  It is a far greater problem to
implement C++ from inside of C code.

I have no doubt that it would be possible to create a compiler that that
could produce CIL bytecode; but, how would you interact with .Net objects?
In the end, you would need to do some kind of transparent conversion to
convert objects to something that could be handled from inside of C code
(ie, structures with function pointers to class methods).  Even then, it is
going to be difficult to handle object relationships such as inheritance.

Tim Harig <usernet@ilthio.net> writes:

> On 2009-06-25, jameskuyper <jameskuyper@verizon.net> wrote:
>> Tim Harig wrote:
>>> I don't know of any C compiler targeted for the CLI; and, I don't know how
>>> such a thing would work since the CIL is fundimentally based in object
>>> technology. C++ != C.
>>
>> I'm not sure what you're suggesting by that last comment. Almost every
>> feature of C90, and (in the latest C++ standard, several of the new
>> features in C99) is also a feature of C++. If there's any feature of C
>> that can't be implemented in CLI, it seems to me that the
>> corresponding C++ feature would also not be implementable.
>
> Yes, seeing as C++ was origionally a superset, it is generally possible to
> implement C from inside of C++ code.  It is a far greater problem to
> implement C++ from inside of C code.
>
> I have no doubt that it would be possible to create a compiler that that
> could produce CIL bytecode; but, how would you interact with .Net objects?
> In the end, you would need to do some kind of transparent conversion to
> convert objects to something that could be handled from inside of C code
> (ie, structures with function pointers to class methods).  Even then, it is
> going to be difficult to handle object relationships such as
> inheritance.

Its why almost no one uses mono/CLI/whatever.

It's as clear as mud.


-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

"Tim Harig" <usernet@ilthio.net> ha scritto nel messaggio
news:H9M0m.3641$Rb6.1256@flpi147.ffdc.sbc.com...
> On 2009-06-25, Chris M. Thomasson <no@spam.invalid> wrote:
>> CLI stands for `Common Language Infrastructure'. It was created by Microsoft
>> and is standardized by the ECMA and is also approved by the ISO (ISO/IEC
>> 23271:2006). The Mono project created an implementation of the CLI that
>> works on Windows, Linux, Mac, BSD.

what is a CLI it is a set of micro instructions?
it is a set of micro instruction for an OS?
it is a set of instruction for a virtual cpu?

> I don't know of any C compiler targeted for the CLI; and, I don't know how
> such a thing would work since the CIL is fundimentally based in object
> technology. C++ != C.

i think that C that has its result in the cli instructions could be possible
like the java compiler that give its micro instructions for java machine
like the asm result of a C compiler for the cpu

i think many compiler has their result for CLI, C, C++, pascal, Delphi
are in the number.

>> C# is based on the CLI. You can write programs in C# and have them run on
>> any platform with binary compatibility

i think these people realize portability so among them could not speak
always for potability (and undefinited behaviour too) :)

>> which has an implementation of the
>> CLI.
>
> C# != C.

On 2009-06-25, io_x <a@b.c.invalid> wrote:
>
> "Tim Harig" <usernet@ilthio.net> ha scritto nel messaggio
> news:H9M0m.3641$Rb6.1256@flpi147.ffdc.sbc.com...
>> On 2009-06-25, Chris M. Thomasson <no@spam.invalid> wrote:
>>> CLI stands for `Common Language Infrastructure'. It was created by Microsoft
>>> and is standardized by the ECMA and is also approved by the ISO (ISO/IEC
>>> 23271:2006). The Mono project created an implementation of the CLI that
>>> works on Windows, Linux, Mac, BSD.
> what is a CLI it is a set of micro instructions?
> it is a set of micro instruction for an OS?
> it is a set of instruction for a virtual cpu?

The CLI is a collective term for a number of components.  The CLI has a
virtual machine intereter known as the CLR (Common Language Runtime).  The
CLR interpets instructions written in CIL (Common Intermediate Language).

>> I don't know of any C compiler targeted for the CLI; and, I don't know how
>> such a thing would work since the CIL is fundimentally based in object
>> technology. C++ != C.
> i think that C that has its result in the cli instructions could be possible
> like the java compiler that give its micro instructions for java machine
> like the asm result of a C compiler for the cpu

Yes, a C compiler can could create CIL; but, the CLI is more then just the
CLR.  It also includes class libraries which would be required for
doing things like GUI programming, IO operations, etc.  The .Net libraries
are build on based on objects which C generally doesn't have syntax for
managing.  What good is having a C compiler in a framework where you cannot
access the Libraries?

"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:4a43a558$0$1110$4fafbaef@reader3.news.tin.it...
> i think these people realize portability so among them could not speak
> always for potability (and undefinited behaviour too) :)
if i think more
in how i see the situation, for doing the final
cut for the portability speak;

there is a need of a virtual-cpu(with cli-instruction) and a virtual OS

it is not enought the virtual cpu there is need a set of common function
for the virtual OS that have the same result in every real cpu-os combination

"Richard" <rgrdev_@gmail.com> wrote in message 
news:h208gm$k5s$7@news.eternal-september.org...
> Tim Harig <usernet@ilthio.net> writes:
>
>> On 2009-06-25, jameskuyper <jameskuyper@verizon.net> wrote:
>>> Tim Harig wrote:
>>>> I don't know of any C compiler targeted for the CLI; and, I don't know 
>>>> how
>>>> such a thing would work since the CIL is fundimentally based in object
>>>> technology. C++ != C.
>>>
>>> I'm not sure what you're suggesting by that last comment. Almost every
>>> feature of C90, and (in the latest C++ standard, several of the new
>>> features in C99) is also a feature of C++. If there's any feature of C
>>> that can't be implemented in CLI, it seems to me that the
>>> corresponding C++ feature would also not be implementable.
>>
>> Yes, seeing as C++ was origionally a superset, it is generally possible 
>> to
>> implement C from inside of C++ code.  It is a far greater problem to
>> implement C++ from inside of C code.
>>
>> I have no doubt that it would be possible to create a compiler that that
>> could produce CIL bytecode; but, how would you interact with .Net 
>> objects?
>> In the end, you would need to do some kind of transparent conversion to
>> convert objects to something that could be handled from inside of C code
>> (ie, structures with function pointers to class methods).  Even then, it 
>> is
>> going to be difficult to handle object relationships such as
>> inheritance.
>
> Its why almost no one uses mono/CLI/whatever.
>
> It's as clear as mud.

Why do you think that almost nobody uses C#? 

"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:4a43aad3$0$18936$4fafbaef@reader2.news.tin.it...
> "io_x" <a@b.c.invalid> ha scritto nel messaggio
> news:4a43a558$0$1110$4fafbaef@reader3.news.tin.it...
>> i think these people realize portability so among them could not speak
>> always for potability (and undefinited behaviour too) :)
> if i think more
> in how i see the situation, for doing the final
> cut for the portability speak;
>
> there is a need of a virtual-cpu(with cli-instruction) and a virtual OS
>
> it is not enought the virtual cpu there is need a set of common function
> for the virtual OS that have the same result in every real cpu-os combination

possibily these function can be called from many programming language
from asm to VB

all other can be written in cli-instruction, or in some language that
has its cli traslation (class operators etc etc)

"Tim Harig" <usernet@ilthio.net> ha scritto nel messaggio
news:8QN0m.1598$bq1.197@nlpi066.nbdc.sbc.com...
> On 2009-06-25, io_x <a@b.c.invalid> wrote:
>> i think that C that has its result in the cli instructions could be possible
>> like the java compiler that give its micro instructions for java machine
>> like the asm result of a C compiler for the cpu
>
> Yes, a C compiler can could create CIL; but, the CLI is more then just the
> CLR.  It also includes class libraries which would be required for
> doing things like GUI programming, IO operations, etc.  The .Net libraries
> are build on based on objects which C generally doesn't have syntax for
> managing.  What good is having a C compiler in a framework where you cannot
> access the Libraries?

the binary portability (so no undefinite bheaviour)

i think i can use the C++ functions,
class, operators and constructors even in plain assembly knowing the names
the C++ assign to them (and knowing what they do too)

if the languge scale well it is possible doing all
from HLL to Asm; from Asm to HLL like in C++

but i don't know for .Net library, if it is too much complex

"Chris M. Thomasson" <no@spam.invalid> wrote:

> "Kenny McCormack" <gazelle@shell.xmission.com> wrote in message 
> > Keith Thompson  <kst-u@mib.org> wrote:
> >>jacob navia <jacob@nospam.org> writes:
> >>> Yes, for the details for the windows system read Petzold's book.
> >>> It is very easy to read, and starts at the beginning
> >>
> >>But be aware that what you learn will be largely inapplicable to
> >>non-Windows systems.

And also that what he writes about C itself is not always accurate. In
other words, first learn C, _then_ read Petzold. But if what you want to
know about is programming for MS Windows specifically, Petzold is good.

> > Yes, much as what you learn about life on planet Earth will be largely
> > inapplicable when you take up residence on some other planet.
> 
> What planet do you live on? 

He lives on only 30% of planet Earth, obviously.

Richard

In article <4a438e9e.2293515@news.xs4all.nl>,
Richard Bos <rlbos@xs4all.nl> wrote:
....
>> > Yes, much as what you learn about life on planet Earth will be largely
>> > inapplicable when you take up residence on some other planet.
>> 
>> What planet do you live on? 

A bit of clarification.  I'm not saying that Windows is the only
platform on which C prograqms can be compiled and/or run, as some of you
seem to be implying.  Obviously, such a position would be absurd.

Nor am I saying that most (or even many) of the posters to CLC hold the
view that the sun rises and sets with Windows.  Such a position would be
equally absurd.  However, it is true that there are many people in the
real world who hold such a view - just as a generation or so back, there
were many people for whom the totality of the concept of "computing" was
the IBM 360.  And I believe that OP in this thread was one such person
(for Windows, that is, not the IBM 360).  Note: You can try to nit-pick
this assertion, but I really don't care.  If you think it isn't the case
here, then pick any other similar thread (and there have been many over
the years) - where somebody came on here and made it clear that Microsoft
Windows was their universe, and yet they get the usual posts saying
"Well, that won't work everywhere, blah, blah, blah".

My point is that saying "such and such only works on Windows", while
true (and perhaps profound, if the intended audience was one likely to find
it so), is irrelevant, when directed specifically to a person who has made
it clear that Windows is their universe.

>He lives on only 30% of planet Earth, obviously.
>
>Richard

Funny you should say that, since it makes my point well.
In the course of my lifetime, I should think myself doing well if I do
end up touching anywhere near 30% of planet Earth.  And that's the
point, that most people really only care about their little corner or
corners of the computing universe.  Those corners really are all that
matter (to them).

On 2009-06-25, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> My point is that saying "such and such only works on Windows", while
> true (and perhaps profound, if the intended audience was one likely to find
> it so), is irrelevant, when directed specifically to a person who has made
> it clear that Windows is their universe.

1.  Shouldn't the original post always be the gold standard seeing as they
	will have to implement any solutions on their target systems?  In
	this case, Z.zen didn't specify what his target OS or environment
	is so, solutions for any given os/environment should be acceptable.
	If he OP doesn't get solutions that work with his target
	environment, then he should have clarified.

2.  In the post that started this branch of the thread, jacob navia stated:

	"for the details for the windows system"

	thereby making it clear that his reply was regarding Windows.  I
	would have used a similar technique if I had posted a solution that
	was unique to Unix and since the OP never clarified his intentions
	it is perfectly valid to give a Windows native solution since he
	was clear about its non-portable nature.  Re-stating that it is not
	portable was needlessly redundant.

> end up touching anywhere near 30% of planet Earth.  And that's the
> point, that most people really only care about their little corner or
> corners of the computing universe.  Those corners really are all that
> matter (to them).

1. It is perfectly valid that people should only be concerned about their
	own environment and sometimes non-portable solutions are perfectly
	valid if they provide enough advantages where no other way exists.

2. That said, good programmers should always consider their alternatives
	and portablility is always one aspect that they should take into
	account and try to achieve if possible.  Pointing out where a
	solution might not be portable, is therefore a reasonable addition
	to the discussion *if* a reasonable cross-platform alternative is
	given.  Its not a bad thing to remind people that they may one day
	need to support another platform.

On 25 June, 20:13, gaze...@shell.xmission.com (Kenny McCormack) wrote:
> In article <4a438e9e.2293...@news.xs4all.nl>,Richard Bos <rl...@xs4all.nl=
> wrote:

windows is not the only OS

> >> > Yes, much as what you learn about life on planet Earth will be large=
ly
> >> > inapplicable when you take up residence on some other planet.
>
> >> What planet do you live on?
>
> A bit of clarification. =A0I'm not saying that Windows is the only
> platform on which C prograqms can be compiled and/or run, as some of you
> seem to be implying. =A0Obviously, such a position would be absurd.

the original poster was asking about a graphical GUI, which eliminates
a good chunk of the platforms out there


> Nor am I saying that most (or even many) of the posters to CLC hold the
> view that the sun rises and sets with Windows. =A0Such a position would b=
e
> equally absurd. =A0However, it is true that there are many people in the
> real world who hold such a view [...] And I believe that OP in this
> thread was one such person [...]. =A0

I think it highly likely. As a rule of thumb if they don't say
what their platform is its highly likely its windows (because a
lot of windows people don't even realise there *are* other platforms).


> Note: You can try to nit-pick
> this assertion, but I really don't care. =A0If you think it isn't the cas=
e
> here, then pick any other similar thread (and there have been many over
> the years) - where somebody came on here and made it clear that Microsoft
> Windows was their universe, and yet they get the usual posts saying
> "Well, that won't work everywhere, blah, blah, blah".

so why not educate them? I've got no problem with pointing people
at Petzold but why not also explain tothem that GUIs have portability
issues. And in fact if we have guessed wrong then P will pretty well
be a waste of space.

Your posting history indicates that won't agree with me but I
consider it a good thing to have a multiplicity of views.


> My point is that saying "such and such only works on Windows", while
> true (and perhaps profound, if the intended audience was one likely to fi=
nd
> it so), is irrelevant, when directed specifically to a person who has mad=
e
> it clear that Windows is their universe.

wasn't that clear

> >He lives on only 30% of planet Earth, obviously.
>
> >Richard
>
> Funny you should say that, since it makes my point well.
> In the course of my lifetime, I should think myself doing well if I do
> end up touching anywhere near 30% of planet Earth.

since 67% of it is ocean...

>=A0And that's the
> point, that most people really only care about their little corner or
> corners of the computing universe. =A0Those corners really are all that
> matter (to them).

so we educate them and the world becomesa better place

Nick Keighley said:

<snip>
 
> the original poster was asking about a graphical GUI, which
> eliminates a good chunk of the platforms out there

....but still leaves a good many. I'm thinking of the non-"computer" 
things around my home that have GUIs - the mobile phones, the CD 
player, the keyboard (musical variety), the recording desk (which, 
despite being a dedicated desk, has sockets for (optionally) 
plugging in keyboard, mouse and monitor)... the list of 
GUI-supporting products (and therefore platforms) is getting 
longer, and will continue to grow as computer-based innovations 
continue to accelerate.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Forged article? See 
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999

On 2009-06-26, Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> On 25 June, 20:13, gaze...@shell.xmission.com (Kenny McCormack) wrote:
>> Nor am I saying that most (or even many) of the posters to CLC hold the
>> view that the sun rises and sets with Windows. �Such a position would be
>> equally absurd. �However, it is true that there are many people in the
>> real world who hold such a view [...] And I believe that OP in this
>> thread was one such person [...]. �
>
> I think it highly likely. As a rule of thumb if they don't say
> what their platform is its highly likely its windows (because a

If this was a C++ group, I would agree; however, I question how much
C89,C99 code is being generated for the Windows platform.  Most user
programs are now GUI based and most modern GUIs are highly object oriented.

Unix, however, is intimately tied to the C language.  While there is
certainly C++ penetration, there are still a lot of projects in C.  Since I
do most of my work from a terminal, my perception is probably tainted; but,
a large majority of the programs that I use on a regular basis where
written in C.  I doubt the same could be said for the Windows programs that
I use.

Since the OP didn't specify, I would expect a wide range of solutions.  If
he doesn't get what he wants then it is his fault for not giving enough
information.

> lot of windows people don't even realise there *are* other platforms).

If he is asking about the C language then he is a programmer.  One would
expect most programmers to be savy about the range of computer environments
available.

Tim Harig wrote:
> On 2009-06-25, jameskuyper <jameskuyper@verizon.net> wrote:
>> Tim Harig wrote:
>>> I don't know of any C compiler targeted for the CLI; and, I don't know how
>>> such a thing would work since the CIL is fundimentally based in object
>>> technology. C++ != C.
>> I'm not sure what you're suggesting by that last comment. Almost every
>> feature of C90, and (in the latest C++ standard, several of the new
>> features in C99) is also a feature of C++. If there's any feature of C
>> that can't be implemented in CLI, it seems to me that the
>> corresponding C++ feature would also not be implementable.
> 
> Yes, seeing as C++ was origionally a superset, it is generally possible to
> implement C from inside of C++ code.  It is a far greater problem to
> implement C++ from inside of C code.
> 
> I have no doubt that it would be possible to create a compiler that that
> could produce CIL bytecode; but, how would you interact with .Net objects?


So, you're not saying that a C compiler targeted at CLI would be 
impossible, or even necessarily difficult, but only that CLI offers some 
features that are not in the the C language itself? That doesn't seem as 
serious a problem as implied by your original comment above. I don't 
expect the C language and the C standard library to do everything; 
nothing is more commonplace than the need for one or more libraries in 
addition to the C standard library, to access additional features of a 
given platform.

How difficult would it be to define a library, separate from the C 
standard library, that provided access to those extra CLI features 
through a C interface? You'd probably want the compiler to be on 
intimate terms with this other library, so that it could inline calls 
that correspond directly to CLI bytecode. There's probably other way to 
do this, such as language extensions, but I prefer a library if it's at 
all feasible to provide the functionality in that form.

"James Kuyper" <jameskuyper@verizon.net> wrote in message 
news:4v11m.1256$9l4.502@nwrddc01.gnilink.net...
> Tim Harig wrote:

>> I have no doubt that it would be possible to create a compiler that that
>> could produce CIL bytecode; but, how would you interact with .Net 
>> objects?
>
>
> So, you're not saying that a C compiler targeted at CLI would be 
> impossible, or even necessarily difficult, but only that CLI offers some 
> features that are not in the the C language itself? That doesn't seem as 
> serious a problem as implied by your original comment above. I don't 
> expect the C language and the C standard library to do everything; nothing 
> is more commonplace than the need for one or more libraries in addition to 
> the C standard library, to access additional features of a given platform.

It sounds like it would be difficult to exploit the advantages of C when 
targetting CLI (eg. speed and low-level access).

While probably not impossible, why not just use something like C# which is a 
more modern and polished language?

In other words, C is better off being used when targetting native code.

-- 
Bart 

James Kuyper wrote:
> 
> So, you're not saying that a C compiler targeted at CLI would be 
> impossible, or even necessarily difficult, but only that CLI offers some 
> features that are not in the the C language itself? That doesn't seem as 
> serious a problem as implied by your original comment above. I don't 
> expect the C language and the C standard library to do everything; 
> nothing is more commonplace than the need for one or more libraries in 
> addition to the C standard library, to access additional features of a 
> given platform.
> 
> How difficult would it be to define a library, separate from the C 
> standard library, that provided access to those extra CLI features 
> through a C interface? You'd probably want the compiler to be on 
> intimate terms with this other library, so that it could inline calls 
> that correspond directly to CLI bytecode. There's probably other way to 
> do this, such as language extensions, but I prefer a library if it's at 
> all feasible to provide the functionality in that form.
> 

The lcc compiler runs under the .net environment, what
is the same as this "CLI"

On 26 June, 09:34, Tim Harig <user...@ilthio.net> wrote:
> On 2009-06-26, Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> > On 25 June, 20:13, gaze...@shell.xmission.com (Kenny McCormack) wrote:


> >> Nor am I saying that most (or even many) of the posters to CLC hold th=
e
> >> view that the sun rises and sets with Windows. =A0Such a position woul=
d be
> >> equally absurd. =A0However, it is true that there are many people in t=
he
> >> real world who hold such a view [...] And I believe that OP in this
> >> thread was one such person [...]. =A0
>
> > I think it highly likely. As a rule of thumb if they don't say
> > what their platform is its highly likely its windows (because a
>
> If this was a C++ group, I would agree; however, I question how much
> C89,C99 code is being generated for the Windows platform. =A0Most user
> programs are now GUI based and most modern GUIs are highly object oriente=
d.

Is windows a modern GUI environment? The Win32 interface is a C
interface. It tries to be OO. I actually quite like it. But you
can program it in C. Petzold used to be all C.


> Unix, however, is intimately tied to the C language. =A0While there is
> certainly C++ penetration, there are still a lot of projects in C. =A0Sin=
ce I
> do most of my work from a terminal, my perception is probably tainted; bu=
t,
> a large majority of the programs that I use on a regular basis where
> written in C. =A0I doubt the same could be said for the Windows programs =
that
> I use.
>
> Since the OP didn't specify, I would expect a wide range of solutions. =
=A0If
> he doesn't get what he wants then it is his fault for not giving enough
> information.
>
> > lot of windows people don't even realise there *are* other platforms).
>
> If he is asking about the C language then he is a programmer. =A0One woul=
d
> expect most programmers to be savy about the range of computer environmen=
ts
> available.

never under-estimate human ignorance

Nick Keighley wrote:
>>
>>> lot of windows people don't even realise there *are* other platforms).
>> If he is asking about the C language then he is a programmer.  One would
>> expect most programmers to be savy about the range of computer environments
>> available.
> 
> never under-estimate human ignorance
> 
> 

neither human arrogance should be underestimated.

On 2009-06-26, James Kuyper <jameskuyper@verizon.net> wrote:
> Tim Harig wrote:
>> On 2009-06-25, jameskuyper <jameskuyper@verizon.net> wrote:
>>> Tim Harig wrote:
>>>> I don't know of any C compiler targeted for the CLI; and, I don't know how
>>>> such a thing would work since the CIL is fundimentally based in object
>>>> technology. C++ != C.
>>> I'm not sure what you're suggesting by that last comment. Almost every
>>> feature of C90, and (in the latest C++ standard, several of the new
>>> features in C99) is also a feature of C++. If there's any feature of C
>>> that can't be implemented in CLI, it seems to me that the
>>> corresponding C++ feature would also not be implementable.
>> Yes, seeing as C++ was origionally a superset, it is generally possible to
>> implement C from inside of C++ code.  It is a far greater problem to
>> implement C++ from inside of C code.
>> I have no doubt that it would be possible to create a compiler that that
>> could produce CIL bytecode; but, how would you interact with .Net objects?
>
> So, you're not saying that a C compiler targeted at CLI would be 
> impossible, or even necessarily difficult, but only that CLI offers some 
> features that are not in the the C language itself? That doesn't seem as 

Yes precisely.

> serious a problem as implied by your original comment above. I don't 
> expect the C language and the C standard library to do everything; 
> nothing is more commonplace than the need for one or more libraries in 
> addition to the C standard library, to access additional features of a 
> given platform.

The challange is not just to create an interface but to do so in a way that
would be natural for both the C langauge and the .Net environment.  A large
part of the promise of the .Net Framework is that it works almost
identically between different languages.  The object interactions for an
algorithm should look identical even if the control structures of two
languages diverge.

Jscript, VBscript, Python, and any other language used for client side
scripting inside of a web browser look almost identical.  Where their
varius control models diverge, the data models are all based on the same
DOM objects.  The same is true inside of WSH where all of the functionality
is provided by the WScript or CScript objects.  In the end, the langauges
are just convinient means to manipulate the objects.

..Net is equivilant.  Powershell and C# both access and use the framework in
an almost identical way even though they both have extremely different
structures of logical flow and syntactic sugar.  If a C library and
implementation cannot accurately recreate not only the functionallity but
the esthetic style present in the other .Net langauges, then it is an
outsider to the platform.

> How difficult would it be to define a library, separate from the C 
> standard library, that provided access to those extra CLI features 
> through a C interface? You'd probably want the compiler to be on 
> intimate terms with this other library, so that it could inline calls 
> that correspond directly to CLI bytecode. There's probably other way to 
> do this, such as language extensions, but I prefer a library if it's at 
> all feasible to provide the functionality in that form.

I suspect you would need a runtime marshalling agent operating between
*any* C only interface.  It would handle transparent remapping of things
which could not be known when the C code was compiled.  

It may then still be necessary to add some syntactic sugar as an
extension to the C stanard to match the calling convention used by the
other .Net languages.  I have seen some very object oriented C; but, I
cannot foresee anything which could express the .Net framework
relationships on more then a functional level using function based
calling conventions.

In the end, you spend a momentus amount a work while risking creating
langauge that is neither C nor .Net.  It is likely that you would have
reaped better results by using a language that by its object oriented
nature already fits nicely into the framework.

I am very fond of the C langauge; but, I do not suppose that it is perfect
for everything.  A hammer can drive a screw; but, it is no replacement for
a screwdriver.

On 2009-06-26, jacob navia <jacob@jacob.remcomp.fr> wrote:
> The lcc compiler runs under the .net environment, what
> is the same as this "CLI"

It depends.  The compiler itself could run on the CLR without producing
code which does so (ie, it is possible to write a compiler on the JVM
which produces native code).  It could produce code which runs on the CLR
but doesn't access the CTS or .Net libraries.  Basically, it would just be
using the CLR as a virtual machine without regards to the rest of the .Net
framework.  I wouldn't really consider it a .Net language.

If it natively accesses the .Net framework, using normal .Net conventions
and relationships, I would consider it a .Net langauge, even it it
doesn't necessarily generate CIL code or run on the CLR.

On 2009-06-26, BartC <bartc@freeuk.com> wrote:
>
> "James Kuyper" <jameskuyper@verizon.net> wrote in message 
> news:4v11m.1256$9l4.502@nwrddc01.gnilink.net...
>> Tim Harig wrote:
>>> I have no doubt that it would be possible to create a compiler that that
>>> could produce CIL bytecode; but, how would you interact with .Net 
>>> objects?
>> So, you're not saying that a C compiler targeted at CLI would be 
>> impossible, or even necessarily difficult, but only that CLI offers some 
>> features that are not in the the C language itself? That doesn't seem as 
>> serious a problem as implied by your original comment above. I don't 
>> expect the C language and the C standard library to do everything; nothing 
>> is more commonplace than the need for one or more libraries in addition to 
>> the C standard library, to access additional features of a given platform.
> It sounds like it would be difficult to exploit the advantages of C when 
> targetting CLI (eg. speed and low-level access).
> While probably not impossible, why not just use something like C# which is a 
> more modern and polished language?
> In other words, C is better off being used when targetting native code.

Yep, use the right tool for the right job.

"Chris M. Thomasson" <no@spam.invalid> writes:

> "Richard" <rgrdev_@gmail.com> wrote in message 
> news:h208gm$k5s$7@news.eternal-september.org...
>> Tim Harig <usernet@ilthio.net> writes:
>>
>>> On 2009-06-25, jameskuyper <jameskuyper@verizon.net> wrote:
>>>> Tim Harig wrote:
>>>>> I don't know of any C compiler targeted for the CLI; and, I don't know 
>>>>> how
>>>>> such a thing would work since the CIL is fundimentally based in object
>>>>> technology. C++ != C.
>>>>
>>>> I'm not sure what you're suggesting by that last comment. Almost every
>>>> feature of C90, and (in the latest C++ standard, several of the new
>>>> features in C99) is also a feature of C++. If there's any feature of C
>>>> that can't be implemented in CLI, it seems to me that the
>>>> corresponding C++ feature would also not be implementable.
>>>
>>> Yes, seeing as C++ was origionally a superset, it is generally possible 
>>> to
>>> implement C from inside of C++ code.  It is a far greater problem to
>>> implement C++ from inside of C code.
>>>
>>> I have no doubt that it would be possible to create a compiler that that
>>> could produce CIL bytecode; but, how would you interact with .Net 
>>> objects?
>>> In the end, you would need to do some kind of transparent conversion to
>>> convert objects to something that could be handled from inside of C code
>>> (ie, structures with function pointers to class methods).  Even then, it 
>>> is
>>> going to be difficult to handle object relationships such as
>>> inheritance.
>>
>> Its why almost no one uses mono/CLI/whatever.
>>
>> It's as clear as mud.
>
> Why do you think that almost nobody uses C#? 
>
>

I didn't say almost no one uses c#

I said very few use Mono (or that was my intent). Sorry, if I was not
clear.


-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

In fact, you may not need to use c for designing the gui for your c
code. For instance, you can use java native interface to communicate
with java interface and design the gui with java swing. Even you can
use swig to communicate your code with any language like python,
java , c++ , mono , lua , perl etc... Actually most of the programming
languages have some interface for enabling communication with c code,
for instance perl has inline module for this purpose. But of course
you can also design your gui in c too  as mentioned above by using
motif, x etc ... and even opengl.

"Chris M. Thomasson" <no@spam.invalid> wrote:

> "Kenny McCormack" <gazelle@shell.xmission.com> wrote in message 
> > Richard  <rgrdev_@gmail.com> wrote:
> > ...
> >>>> What do you mean "it ports CLI to Linux" ? What do you mean by CLI 
> >>>> here?

> > For the benefit of those of us who don't go to arbitrary links posted on
> > the Usenet, what the h*** is it?  20 words will do.
> 
> CLI stands for `Common Language Infrastructure'. It was created by Microsoft 

Oh, glorious. Yet another thing stolen, taken over, and turned into
obfuscation by Micro$oft.

Where I come from, CLI stands for "Command Line Interface", and has done
so ever since the first non-CLI WIMP environment was invented, possibly
before. This meaning takes precedence over Micro$oft's appropriation.

Richard

raltbos@xs4all.nl (Richard Bos) writes:
> "Chris M. Thomasson" <no@spam.invalid> wrote:
>
>> "Kenny McCormack" <gazelle@shell.xmission.com> wrote in message 
>> > Richard  <rgrdev_@gmail.com> wrote:
>> > ...
>> >>>> What do you mean "it ports CLI to Linux" ? What do you mean by CLI 
>> >>>> here?
>
>> > For the benefit of those of us who don't go to arbitrary links posted on
>> > the Usenet, what the h*** is it?  20 words will do.
>> 
>> CLI stands for `Common Language Infrastructure'. It was created by Microsoft 
>
> Oh, glorious. Yet another thing stolen, taken over, and turned into
> obfuscation by Micro$oft.
>
> Where I come from, CLI stands for "Command Line Interface", and has done
> so ever since the first non-CLI WIMP environment was invented, possibly
> before. This meaning takes precedence over Micro$oft's appropriation.

And just to piss the linux weenies off, they'll be adopting "TUX" to 
mean something next...

Ooops,
Phil
-- 
Marijuana is indeed a dangerous drug.  
It causes governments to wage war against their own people.
-- Dave Seaman (sci.math, 19 Mar 2009)

On 2009-07-05, Richard Bos <raltbos@xs4all.nl> wrote:
> Oh, glorious. Yet another thing stolen, taken over, and turned into
> obfuscation by Micro$oft.
>
> Where I come from, CLI stands for "Command Line Interface", and has done
> so ever since the first non-CLI WIMP environment was invented, possibly
> before. This meaning takes precedence over Micro$oft's appropriation.

When were acronyms *ever* unambiguous when dealing with technology; or,
even in real life?

Tim Harig <usernet@ilthio.net> wrote:

> On 2009-07-05, Richard Bos <raltbos@xs4all.nl> wrote:
> > Oh, glorious. Yet another thing stolen, taken over, and turned into
> > obfuscation by Micro$oft.
> >
> > Where I come from, CLI stands for "Command Line Interface", and has done
> > so ever since the first non-CLI WIMP environment was invented, possibly
> > before. This meaning takes precedence over Micro$oft's appropriation.
> 
> When were acronyms *ever* unambiguous when dealing with technology; or,
> even in real life?

No, but honest people and honest companies try to avoid too many
confusing clashes. In this case, Micro$oft knew damned well that "I'm
writing a program for the CLI" already meant something. I cannot
interpret their decision to use that acronym despite that previous
meaning as anything but _intentional_ confusion.

Richard

Richard Bos wrote:
> Tim Harig <usernet@ilthio.net> wrote:
> 
>> On 2009-07-05, Richard Bos <raltbos@xs4all.nl> wrote:
>>> Oh, glorious. Yet another thing stolen, taken over, and turned into
>>> obfuscation by Micro$oft.
>>>
>>> Where I come from, CLI stands for "Command Line Interface", and has done
>>> so ever since the first non-CLI WIMP environment was invented, possibly
>>> before. This meaning takes precedence over Micro$oft's appropriation.
>> When were acronyms *ever* unambiguous when dealing with technology; or,
>> even in real life?
> 
> No, but honest people and honest companies try to avoid too many
> confusing clashes. In this case, Micro$oft knew damned well that "I'm
> writing a program for the CLI" already meant something. I cannot
> interpret their decision to use that acronym despite that previous
> meaning as anything but _intentional_ confusion.
> 
> Richard

Perhaps the children playing in their sandbox in Redmond have never seen 
a command line.

-- 
Joe Wright
"If you think Health Care is expensive now, wait until it's free."

On 2009-07-05, Richard Bos <raltbos@xs4all.nl> wrote:
> Tim Harig <usernet@ilthio.net> wrote:
>> On 2009-07-05, Richard Bos <raltbos@xs4all.nl> wrote:
>> > Oh, glorious. Yet another thing stolen, taken over, and turned into
>> > obfuscation by Micro$oft.
>> > Where I come from, CLI stands for "Command Line Interface", and has done
>> > so ever since the first non-CLI WIMP environment was invented, possibly
>> > before. This meaning takes precedence over Micro$oft's appropriation.
>> When were acronyms *ever* unambiguous when dealing with technology; or,
>> even in real life?
> No, but honest people and honest companies try to avoid too many
> confusing clashes. In this case, Micro$oft knew damned well that "I'm
> writing a program for the CLI" already meant something. I cannot
> interpret their decision to use that acronym despite that previous
> meaning as anything but _intentional_ confusion.

"Proof is one thing.  Innnnuuuuendo is another" 
	~ Harry Morgan as Col. Potter

Considering the number of acronyms used in .NET and the Windows platform in
general, I don't think having a common acronym goes far towards proving
conspiracy.

Microsoft also has a product using the SMS acronym.  Does that mean that
they are against text messaging as well?

Come back again when you have the Halloween document in your hands.

Op Sun, 05 Jul 2009 13:19:20 -0400 schreef Joe Wright:

> Richard Bos wrote:
>> Tim Harig <usernet@ilthio.net> wrote:
>> 
>>> On 2009-07-05, Richard Bos <raltbos@xs4all.nl> wrote:
>>>> Oh, glorious. Yet another thing stolen, taken over, and turned into
>>>> obfuscation by Micro$oft.
>>>>
>>>> Where I come from, CLI stands for "Command Line Interface", and has done
>>>> so ever since the first non-CLI WIMP environment was invented, possibly
>>>> before. This meaning takes precedence over Micro$oft's appropriation.
>>> When were acronyms *ever* unambiguous when dealing with technology; or,
>>> even in real life?
>> 
>> No, but honest people and honest companies try to avoid too many
>> confusing clashes. In this case, Micro$oft knew damned well that "I'm
>> writing a program for the CLI" already meant something. I cannot
>> interpret their decision to use that acronym despite that previous
>> meaning as anything but _intentional_ confusion.
>> 
>> Richard
> 
> Perhaps the children playing in their sandbox in Redmond have never seen 
> a command line.

Then they wouldn't have listened to their fathers and grandmothers
that wrote MS-DOS. Even Vista has something like it.
-- 
Coos

Coos Haak wrote:
> Op Sun, 05 Jul 2009 13:19:20 -0400 schreef Joe Wright:
> 
>> Richard Bos wrote:
>>> Tim Harig <usernet@ilthio.net> wrote:
>>>
>>>> On 2009-07-05, Richard Bos <raltbos@xs4all.nl> wrote:
>>>>> Oh, glorious. Yet another thing stolen, taken over, and turned into
>>>>> obfuscation by Micro$oft.
>>>>>
>>>>> Where I come from, CLI stands for "Command Line Interface", and has done
>>>>> so ever since the first non-CLI WIMP environment was invented, possibly
>>>>> before. This meaning takes precedence over Micro$oft's appropriation.
>>>> When were acronyms *ever* unambiguous when dealing with technology; or,
>>>> even in real life?
>>> No, but honest people and honest companies try to avoid too many
>>> confusing clashes. In this case, Micro$oft knew damned well that "I'm
>>> writing a program for the CLI" already meant something. I cannot
>>> interpret their decision to use that acronym despite that previous
>>> meaning as anything but _intentional_ confusion.
>>>
>>> Richard
>> Perhaps the children playing in their sandbox in Redmond have never seen 
>> a command line.
> 
> Then they wouldn't have listened to their fathers and grandmothers
> that wrote MS-DOS. Even Vista has something like it.

I guess you missed my attempt at humor. Still, there must be tons of 
Windows users who don't know what cmd.exe is.

-- 
Joe Wright
"If you think Health Care is expensive now, wait until it's free."

Coos Haak said:

> Op Sun, 05 Jul 2009 13:19:20 -0400 schreef Joe Wright:
> 
<snip>
 
>> Perhaps the children playing in their sandbox in Redmond have
>> never seen a command line.
> 
> Then they wouldn't have listened to their fathers and grandmothers
> that wrote MS-DOS. Even Vista has something like it.

Tim Paterson, who wrote MS-DOS (originally called QDOS and, briefly, 
86-DOS), has never been a grandmother. Whether he is a father, I 
don't know. That he is a father of a Microsoft employee is 
reasonably unlikely. At the time that he wrote what later became 
known as MS-DOS, he was working for Seattle Computer Products, not 
Microsoft.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Forged article? See 
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999

Tim Harig <usernet@ilthio.net> wrote:

> On 2009-07-05, Richard Bos <raltbos@xs4all.nl> wrote:
> > Tim Harig <usernet@ilthio.net> wrote:
> >> On 2009-07-05, Richard Bos <raltbos@xs4all.nl> wrote:
> >> > Oh, glorious. Yet another thing stolen, taken over, and turned into
> >> > obfuscation by Micro$oft.
> >> > Where I come from, CLI stands for "Command Line Interface", and has done
> >> > so ever since the first non-CLI WIMP environment was invented, possibly
> >> > before. This meaning takes precedence over Micro$oft's appropriation.
> >> When were acronyms *ever* unambiguous when dealing with technology; or,
> >> even in real life?
> > No, but honest people and honest companies try to avoid too many
> > confusing clashes. In this case, Micro$oft knew damned well that "I'm
> > writing a program for the CLI" already meant something. I cannot
> > interpret their decision to use that acronym despite that previous
> > meaning as anything but _intentional_ confusion.
> 
> "Proof is one thing.  Innnnuuuuendo is another" 
> 	~ Harry Morgan as Col. Potter

I SEE NO innuendo HERE.

> Considering the number of acronyms used in .NET and the Windows platform in
> general, I don't think having a common acronym goes far towards proving
> conspiracy.

No, but Microsoft's extensive history of embrace-and-extend does.

> Microsoft also has a product using the SMS acronym.  Does that mean that
> they are against text messaging as well?

Is that acronym used in a context where it is easily confused with
mobile phones? No, I don't think so. More importantly, there is nothing
in text messaging for Microsoft to make a lot of money out of or
establish a near monopoly in by underhand practices, as is their habit,
so there's no reason for them to enter that business.

Richard

On 2009-07-10, Richard Bos <raltbos@xs4all.nl> wrote:
> Tim Harig <usernet@ilthio.net> wrote:
>> On 2009-07-05, Richard Bos <raltbos@xs4all.nl> wrote:
>> > Tim Harig <usernet@ilthio.net> wrote:
>> >> On 2009-07-05, Richard Bos <raltbos@xs4all.nl> wrote:
>> >> > Oh, glorious. Yet another thing stolen, taken over, and turned into
>> >> > obfuscation by Micro$oft.
>> >> > Where I come from, CLI stands for "Command Line Interface", and has done
>> >> > so ever since the first non-CLI WIMP environment was invented, possibly
>> >> > before. This meaning takes precedence over Micro$oft's appropriation.
>> >> When were acronyms *ever* unambiguous when dealing with technology; or,
>> >> even in real life?
>> > No, but honest people and honest companies try to avoid too many
>> > confusing clashes. In this case, Micro$oft knew damned well that "I'm
>> > writing a program for the CLI" already meant something. I cannot
>> > interpret their decision to use that acronym despite that previous
>> > meaning as anything but _intentional_ confusion.
>> 
>> "Proof is one thing.  Innnnuuuuendo is another" 
>> 	~ Harry Morgan as Col. Potter
> I SEE NO innuendo HERE.

Still, you provide no proof of you claims.

>> Considering the number of acronyms used in .NET and the Windows platform in
>> general, I don't think having a common acronym goes far towards proving
>> conspiracy.
> No, but Microsoft's extensive history of embrace-and-extend does.

So prove that is is a part of Microsoft's embace-and-extend stratagy.

Tim Harig wrote:
>>> Considering the number of acronyms used in .NET and the Windows platform in
>>> general, I don't think having a common acronym goes far towards proving
>>> conspiracy.
>> No, but Microsoft's extensive history of embrace-and-extend does.
> 
> So prove that is is a part of Microsoft's embace-and-extend stratagy.

Imagine...

Steve Ballmer and William Gates discussing late night in Redmond:

o Steve: How can we beat the Linux crowd?

o William: We can steal them the command line interface! That's
       the only thing that works in their system.

o Steve: Excellent idea. Linux without a CLI just doesn't work.
          Mmmmm. But HOW?

o William: We will start a new software project with the name CLI
            of course. That will surely kill them.


That is how the .NET project was born.

:-)