1. About .NET
The next version of Windows will be coming in about two years. This version
will have an entirely new programming model using the .NET platform.
To those of you who are not famaliar with .NET, it is similar to Java in that it
uses a virtual machine to run the program. One of its key advantages over Java
however, is that you can use it in a variety of programming languages, not just
one. I thing there are over 65 programming languages that can create .NET
applications.
2. Re: About .NET
Philip Deets wrote:
>
> The next version of Windows will be coming in about two years. This version
> will have
> an entirely new programming model using the .NET platform.
> To those of you who are not famaliar with .NET, it is similar to Java in that
> it uses
> a virtual machine to run the program. One of its key advantages over Java
> however,
> is that you can use it in a variety of programming languages, not just one. I
> thing
> there are over 65 programming languages that can create .NET applications.
At work, we create .NET-applications in C# that operate over the Internet
(client/server), and I have to say: it's very cool. A lot of what you need is
already in the base class libraries: networking, database access (SQL Server,
Oracle, ODBC, OleDB, ...), graphics, XML, Regular Expressions, Windows Forms, ...
I've already thought of creating a .NET-version of Euphoria (Euphoria.NET or E#
?). A Euphoria-compiler could easily be written in C#, since the .NET framework
already has classes that let you create IL-code (IL = intermediate language, the
bytecode used by the .NET VM).
The problem is that .NET is completely object-oriented and Euphoria isn't. So
creating a .NET Euphoria-language wouldn't be compatible with RDS Euphoria. But I
think that is not necessary.
--
tommy online: http://users.pandora.be/tommycarlier
Euphoria Message Board: http://uboard.proboards32.com
3. Re: About .NET
Tommy Carlier wrote:
>
> Philip Deets wrote:
> >
> > The next version of Windows will be coming in about two years. This version
> > will have
> > an entirely new programming model using the .NET platform.
> > To those of you who are not famaliar with .NET, it is similar to Java in
> > that it uses
> > a virtual machine to run the program. One of its key advantages over Java
> > however,
> > is that you can use it in a variety of programming languages, not just one.
> > I thing
> > there are over 65 programming languages that can create .NET applications.
>
> At work, we create .NET-applications in C# that operate over the Internet
> (client/server),
> and I have to say: it's very cool. A lot of what you need is already in the
> base class
> libraries: networking, database access (SQL Server, Oracle, ODBC, OleDB, ...),
> graphics,
> XML, Regular Expressions, Windows Forms, ...
> I've already thought of creating a .NET-version of Euphoria (Euphoria.NET or
> E# ?).
> A Euphoria-compiler could easily be written in C#, since the .NET framework
> already
> has classes that let you create IL-code (IL = intermediate language, the
> bytecode used
> by the .NET VM).
> The problem is that .NET is completely object-oriented and Euphoria isn't. So
> creating
> a .NET Euphoria-language wouldn't be compatible with RDS Euphoria. But I think
> that
> is not necessary.
>
> --
> tommy online: <a target=_top
> href="http://users.pandora.be/tommycarlier">http://users.pandora.be/tommycarlier</a>
> Euphoria Message Board: <a target=_top
> href="http://uboard.proboards32.com">http://uboard.proboards32.com</a>
>
That approach would work too, compiling euphoria to .NET, but then that would
eliminate the euphoria runtime. Microsoft would be doing that. I thought maybe
RDS could still run euphoria with their euIL interpretter (coming in v. 2.5), but
I think euphoria ought to be able to run managed code too (like it can C code) so
euphorians can use .NET.
Phil
4. Re: About .NET
Philip Deets wrote:
> I thing there are over 65 programming
> languages that can create .NET applications.
And oddly enough, they all look exactly like C#. That is, all .NET languages
tend to have the same datatypes, control structures, and so on. The .NET
framework works well with compiled languages, but rather poorly with
interpreted languages that have dynamic datatypes.
There are two approaches you can take with .NET: compile to the .NET
intermediate language, or create an interpreter that runs under .NET.
In the first scenario (compile to .NET), you have the advantage of the
language being able to run as a "first class citizen" and having full access
to the .NET library. That's sort of the point of .NET: all languages get
equal access to the same libraries, so they are equally powerful.
In the second (create an interpreter), you end up with a language that runs
under .NET, but doesn't necessarily have any of the advantages of .NET, other
than running under .NET.
I don't see any reason why Euphoria wouldn't be able to work under either
scenario.
-- David Cuny
5. Re: About .NET
David wrote:
>
> Philip Deets wrote:
>
> > I thing there are over 65 programming
> > languages that can create .NET applications.
>
> And oddly enough, they all look exactly like C#. That is, all .NET languages
> tend to have the same datatypes, control structures, and so on. The .NET
> framework works well with compiled languages, but rather poorly with
> interpreted languages that have dynamic datatypes.
>
> There are two approaches you can take with .NET: compile to the .NET
> intermediate language, or create an interpreter that runs under .NET.
>
> In the first scenario (compile to .NET), you have the advantage of the
> language being able to run as a "first class citizen" and having full access
> to the .NET library. That's sort of the point of .NET: all languages get
> equal access to the same libraries, so they are equally powerful.
>
> In the second (create an interpreter), you end up with a language that runs
> under .NET, but doesn't necessarily have any of the advantages of .NET, other
> than running under .NET.
>
> I don't see any reason why Euphoria wouldn't be able to work under either
> scenario.
>
> -- David Cuny
>
>
I just took a quick glance at the IL that all .NET languages translate
into. I don't think it would be difficult to come up with a program
that would translate a Euphoria program into IL. However, here's some
things to consider:
1. It would force us to switch from our favorite Windows API library
to a standard coding for using .NET services. The "standard" could be
anything we want but it would have to be agreed upon. Trying to come up
with a program that would translate all the available Windows API
libraries would be a nightmare. This doesn't rule out someone coming up
with, for example, a win32lib.ew file that would use the Euphoria.NET
coding standard. This would also apply to any other user contributed
library.
2. Euphoria.NET would be a Windows only variant, moving away from the
cross-platform compatability (but of course, isn't this what MS wants?).
3. Euphoria.NET programs would run slower than Euphoria programs coded
to the API.
I also ran a dependency walker against one of the .NET windows form
.dlls and not to my surprise, the dll was linked to comctl32.dll,
kernel32.dll, advapi32.dll, gdi32.dll, user32.dll, comdlg32.dll, etc.
So it would seem that .NET is similar in concept to OWL and MFC in that
it tries to shield the programmer from the Windows API and throws in some
additional services to boot. The reality is that .NET is still based on
the traditional Windows API so seemingly there's no worry that MS might
one day throw away the APIs.
My feeling is that we can continue to code Windows Euphoria programs
for quite some time and they should run fine when MS moves to a ".NET
only" programming environment. Unless I've misinterpreted the signs, I
can't really see any compelling reason to go to all the trouble of
creating Euphoria.NET.
Jonas
The opinions expressed are not necessarily those of this station or
it's affiliates.
6. Re: About .NET
Jonas Temple wrote:
>
> 2. Euphoria.NET would be a Windows only variant, moving away from the
> cross-platform compatability (but of course, isn't this what MS wants?).
This isn't as true as you think. Take a look at
http://www.mono-project.com . It's an open source version of .NET that
also runs on Linux.
> 3. Euphoria.NET programs would run slower than Euphoria programs coded
> to the API.
Perhaps, but would it be noticeable (GUI manipulation doesn't usually take
up a lot of cycles on my apps).
Matt Lewis
7. Re: About .NET
Jonas Temple wrote:
> 2. Euphoria.NET would be a Windows only variant, moving away from the
> cross-platform compatability (but of course, isn't this what MS wants?).
Probably should code for Mono or dotGNU instead of .NET. I will not use
a .NET implementation of anything... ever. (Nor will I ever have to.)
http://www.mono-project.com/about/index.html
http://www.dotgnu.org/
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
8. Re: About .NET
Jonas Temple wrote:
> I just took a quick glance at the IL that all .NET languages translate
> into. I don't think it would be difficult to come up with a program
> that would translate a Euphoria program into IL. However, here's some
> things to consider:
>
> 1. It would force us to switch from our favorite Windows API library
> to a standard coding for using .NET services. The "standard" could be
> anything we want but it would have to be agreed upon. Trying to come up
> with a program that would translate all the available Windows API
> libraries would be a nightmare. This doesn't rule out someone coming up
> with, for example, a win32lib.ew file that would use the Euphoria.NET
> coding standard. This would also apply to any other user contributed
> library.
> 2. Euphoria.NET would be a Windows only variant, moving away from the
> cross-platform compatability (but of course, isn't this what MS wants?).
> 3. Euphoria.NET programs would run slower than Euphoria programs coded
> to the API.
>
> I also ran a dependency walker against one of the .NET windows form
> .dlls and not to my surprise, the dll was linked to comctl32.dll,
> kernel32.dll, advapi32.dll, gdi32.dll, user32.dll, comdlg32.dll, etc.
> So it would seem that .NET is similar in concept to OWL and MFC in that
> it tries to shield the programmer from the Windows API and throws in some
> additional services to boot. The reality is that .NET is still based on
> the traditional Windows API so seemingly there's no worry that MS might
> one day throw away the APIs.
>
> My feeling is that we can continue to code Windows Euphoria programs
> for quite some time and they should run fine when MS moves to a ".NET
> only" programming environment. Unless I've misinterpreted the signs, I
> can't really see any compelling reason to go to all the trouble of
> creating Euphoria.NET.
Sure, Euphoria as it is right now won't stop working. Just like C and C++ and
other languages. The API will still be available for backward compatibility, but
.NET is the future of Windows programming. The Windows.Forms-part of the
.NET-framework is currently "just a wrapper" on top of the Windows API, but .NET
is so much more.
You say that "there's no worry that MS might one day throw away the APIs". I
have bad news for you: the next major version of Windows (LongHorn) is built on
the .NET Framework. LongHorn is .NET. .NET is the core of LongHorn. Managed
.NET-applications (IL) will run faster than native applications that call the
API-functions, which will probably still be there for backward compatibility.
You say: "Euphoria.NET would be a Windows only variant, moving away from the
cross-platform compatability (but of course, isn't this what MS wants?)."
Isn't calling the APIs kind of Windows-only?
Besides, Euphoria.NET is not meant to replace Euphoria, just like C# is not
meant to replace C or C++.
One more point: .NET is not 100% Windows-only. There are alternatives being
built for Linux (http://www.mono-project.com). .NET is not only for building
Windows-applications: most of the .NET-applications being built right now are
ASP.NET-applications: server applications, web services, interactive websites,
etc...
--
tommy online: http://users.pandora.be/tommycarlier
Euphoria Message Board: http://uboard.proboards32.com
9. Re: About .NET
Tommy Carlier wrote:
> You say that "there's no worry that MS might one day throw away the APIs". I
> have bad
> news for you: the next major version of Windows (LongHorn) is built on the
> .NET Framework.
> LongHorn is .NET. .NET is the core of LongHorn. Managed .NET-applications (IL)
> will
> run faster than native applications that call the API-functions, which will
> probably
> still be there for backward compatibility.
>
Maybe I'm reading this wrong but it seems to me that the APIs will be
available in 64 bit form in 64 bit Windows (this from the SDK on MSDN):
<Beginning of quote>
Platform SDK: 64-bit Windows Programming
The Tools
This topic describes the tools available for you to use in making your
application 64-bit ready.
Include Files
The API elements are virtually identical between 32- and 64-bit
Microsoft® Windows®. The Windows header files have been modified so that
you can use them for both 32- and 64-bit code. The new 64-bit types and
macros are defined in a new header file, Basetsd.h, which is in the set
of header files included by Windows.h. Basetsd.h includes the new
data-type definitions you'll use to make your application word-size
independent.
<End of Quote>
So why would they make that statement if they intend on doing away with
the APIs? Can we assume that there will be user64.dll, kernel64.dll,
etc.?
Jonas
10. Re: About .NET
Jonas Temple wrote:
>
> <snip>
>
> My feeling is that we can continue to code Windows Euphoria programs
> for quite some time and they should run fine when MS moves to a ".NET
> only" programming environment. Unless I've misinterpreted the signs, I
> can't really see any compelling reason to go to all the trouble of
> creating Euphoria.NET.
>
> <snip>
Microsoft will probably never move to a .NET only programming environment
for reasons of backward compatibility. However, eventually the current
DLLs will probably not get many new features. All the new things coming
out (like ViewPort3D control that lets you place 3d content on your window
as a control) will only be supported with .NET.
Also the new WinFS file system (Longhorn's NTFS replacement) will be use the
.NET programming environment. All you can do with unmanaged code on it
will be what you can do now (create files and folders), not the new stuff
(like use the file system as a database).
So basically there is no compelling reason to switch. It just would be
really cool.
Phil
11. Re: About .NET
David wrote:
>
> Philip Deets wrote:
>
> > I think there are over 65 programming
> > languages that can create .NET applications.
>
> And oddly enough, they all look exactly like C#. That is, all .NET
> languages tend to have the same datatypes, control structures, and so
> on. The .NET framework works well with compiled languages, but rather
> poorly with interpreted languages that have dynamic datatypes.
>
> <snip>
I'm not sure I understand why .NET would work poorly with a language with
dynamic datatypes. .NET is object oriented. Every class in .NET is a
type.
Even the code
int i = 0;
in C# is just a short form for
System.Int32 i = new System.Int32(0);
Types are classes (or structures, as is the case with the int example).
Also, .NET languages don't look alike to me. Just look at the difference
between VB.NET and C#
VB.NET
' A "Hello World!" program in Visual Basic.
Module Hello
Sub Main()
MsgBox("Hello World!")
End Sub
End Module
C#
// A "Hello World!" program in C#
using System.Windows.Forms;
namespace Hello
{
class Hello
{
public static void Main()
{
MessageBox.Show("Hello World!");
}
}
}
Phil
12. Re: About .NET
"Microsoft will probably never move to a .NET only programming environment
for reasons of backward compatibility."
I fully expect for Windows to evolve and become completely .NET based.
Microsoft never worried that much about backwards compatibility before so
why start now?
13. Re: About .NET
Jeff Houck wrote:
> Microsoft never worried that much about backwards compatibility before so
> why start now?
Actually, Microsoft put a huge amount of work into backward compatability.
However, there's much more willingness with the latest releases of Windows to
break compatibility for the sake of "better" technology than there was in the
past. Witness VB and ASP being .NETified, and breaking backward
compatibility.
Since .NET code will be better "trusted", I think there's already a strong
push to move code to .NET. Ironically, since the WinForms library has already
been declared obsolete in favor of an unwritten new UI, much of the .NET
development has been on the web, not the desktop, where the UI (from the
user's point of view) is pretty much platform agnostic.
-- David Cuny
14. Re: About .NET
David wrote:
>
> Jeff Houck wrote:
>
> > Microsoft never worried that much about backwards compatibility before so
> > why start now?
>
> Actually, Microsoft put a huge amount of work into backward compatability.
> However, there's much more willingness with the latest releases of Windows to
> break compatibility for the sake of "better" technology than there was in the
> past. Witness VB and ASP being .NETified, and breaking backward
> compatibility.
>
Correct. And even then when they .NETified it (I like that word), they
made it be at least close to backward compatible. You had to change
little.
Phil
