Board index » kylix » Re: K questions

Re: K questions


2004-01-04 07:11:52 PM
kylix1
On 01/04/04 06:31 +0900, Atmapuri wrote:
Quote
About the future versions of Kylix. It all depends on the market
situation. Maybe it might even make sense for Kylix 4 in 2005.
By that time, I fear it'll be too late. The 2.6 kernel is already
out in the wild and, to the best of my knowledge, Kylix doesn't
grok 2.6. If we have a year (and maybe a bit) of zero support for
Linux, that's the nail in the coffin, IMO.
I really hate to say this, but I'm now glad that I never got
around to purchasing K3Pro. You just /know/ that the next
Slackware release will be based on 2.6. I wouldn't want to be a
software house dictating to its customers that they have to stay
with 2.4-based kernels for the next year or two on the off-chance
that Borland decides to cough up K4 (based on then-old distros).
These are troubling times.
trane
--
//------------------------------------------------------------
// Trane Francks XXXX@XXXXX.COM Tokyo, Japan
// Practice random kindness and senseless acts of beauty.
 
 

Re:Re: K questions

Mark wrote:
Quote
>The support for CLX in Delphi 8 for W32 is not yet known.
>Delphi 8 for Win32 will be released probably around June 2004.

Ok, then what is that "thing" that they release as Delphi 8 ?
It's officially called "Delphi 8 for the Microsoft .NET framework". Guess
what it is. <g>
--
Rudy Velthuis (TeamB)
"In science one tries to tell people, in such a way as to be understood
by everyone, something that no one ever knew before. But in poetry, it's
the exact opposite."
- Paul Dirac (1902-1984)
 

Re:Re: K questions

Quote
2. Is that true that CLX is no longer supported by D8 ?

When Kylix came out many were demanding VCL for Kylix (instead of CLX
for Delphi).
Now D8 dropping CLX seems obvious, as using the appropriate Framework in
future properly done D8 assemblies (using VCL.NET) should be runnable on
Windows and on Linux.
-Michael
 

{smallsort}

Re:Re: K questions

Hi!
Quote
When Kylix came out many were demanding VCL for Kylix (instead of CLX
for Delphi).

Now D8 dropping CLX seems obvious, as using the appropriate Framework in
future properly done D8 assemblies (using VCL.NET) should be runnable on
Windows and on Linux.
Maybe. But support for native code is far from irrelevant. .NET is "not"
a replacement for it.
Regards!
Atmapuri.
 

Re:Re: K questions

"Atmapuri" < XXXX@XXXXX.COM >wrote:
Quote
>Now D8 dropping CLX seems obvious, as using the appropriate Framework in
>future properly done D8 assemblies (using VCL.NET) should be runnable on
>Windows and on Linux.

Maybe. But support for native code is far from irrelevant. .NET is "not"
a replacement for it.
Like it or not, it sounds like Borland's primary committment to
providing support for native code in Linux will be through its
C++BuilderX and JBuilder products.
Borland says Kylix is not dead, but it seems to me that they're
hinting that future support for Kylix may involve .NET and MONO.
I have no inside information, but it seems to me that may be the
way things are going.
Rick Carter
XXXX@XXXXX.COM
Chair, Paradox/Delphi SIG, Cincinnati PC Users Group
 

Re:Re: K questions

"Atmapuri" < XXXX@XXXXX.COM >wrote:
Quote
Delphi 8 for Win32 will be released probably around June 2004.
What is your source of information? As far as I know, all Borland
has said is that there will be a Win32 update, but there's been
no announcement about what it will be called and what will be
included.
Rick Carter
XXXX@XXXXX.COM
Chair, Paradox/Delphi SIG, Cincinnati PC Users Group
 

Re:Re: K questions

Quote
>2. Is that true that CLX is no longer supported by D8 ?
>

When Kylix came out many were demanding VCL for Kylix (instead of CLX
for Delphi).

Now D8 dropping CLX seems obvious, as using the appropriate Framework in
future properly done D8 assemblies (using VCL.NET) should be runnable on
Windows and on Linux.
Or may be they are taking ne year to be able to deliver a VCL for Linux !?
Didier
 

Re:Re: K questions

Quote
Borland says Kylix is not dead, but it seems to me that they're
hinting that future support for Kylix may involve .NET and MONO.
I have no inside information, but it seems to me that may be the
way things are going.
Borland compiler usually are done in a way that they can compile
themselves. Thus it's likely that there will be a Delphi ->CIL IDE that
runs in a .NET Framework. In a perfect world same will run equally on
Windows/MS.NET and LINUX/MONO.
-Michael
 

Re:Re: K questions

Quote
Or may be they are taking ne year to be able to deliver a VCL for Linux !?
They always said VCL is too much Windows API aware to be ported directly
to Linux. The .NET Framework layer might help here.
-Michael
 

Re:Re: K questions

Quote
But support for native code is far from irrelevant. .NET is "not"
a replacement for it.

Why not ? The .NET way can be thought of as having the compiler drop the
last (processor and OS specific, but source language independent) code
generation and optimization passes and distributing this (previously
intermediate) result as a "CIL-Assembly". The Framework on the target
machine now is doing these passes when loading the "executable" (or on
request as a seperate step storing it into a file, creating a "normal"
exe).
The result for the end user is smaller executable files and bigger
application load times. Side effect might be higer memory usage, but not
necessarily higher execution times. Moreover this offers better ways for
dynamic linking. Of course the possibility to use the same deployed
packet on multiple (including not yet existing existing !) platforms
seems great.
Thus, I think, on the desktop, .NET (or a similar system like JAVA) is
the way to go on the long run.
-Michael
 

Re:Re: K questions

Quote
>Or may be they are taking ne year to be able to deliver a VCL for Linux
>!?

They always said VCL is too much Windows API aware to be ported directly
to Linux. The .NET Framework layer might help here.
"They always said"...
Introducing Mono/.Net means abandonning a true Pascal framework.
IMO, if they go this road, they'll be too late because of Lazarus, and it
will have been a waste of time and lost of market opportunity.
Didier
 

Re:Re: K questions

On Tue, 06 Jan 2004 09:34:01 +0100, Michael Schnell wrote:
Quote
>But support for native code is far from irrelevant. .NET is "not"
>a replacement for it.
>

Why not ? The .NET way can be thought of as having the compiler drop the
last (processor and OS specific, but source language independent) code
generation and optimization passes and distributing this (previously
intermediate) result as a "CIL-Assembly". The Framework on the target
machine now is doing these passes when loading the "executable" (or on
request as a seperate step storing it into a file, creating a "normal"
exe).

The result for the end user is smaller executable files and bigger
application load times. Side effect might be higer memory usage, but not
necessarily higher execution times. Moreover this offers better ways for
dynamic linking. Of course the possibility to use the same deployed
packet on multiple (including not yet existing existing !) platforms
seems great.

Thus, I think, on the desktop, .NET (or a similar system like JAVA) is
the way to go on the long run.

-Michael
The result for the end user is smaller executable files and bigger
application load times. Side effect might be higer memory usage, but not
necessarily higher execution times. Moreover this offers better ways for
dynamic linking. Of course the possibility to use the same deployed
packet on multiple (including not yet existing existing !) platforms
seems great.

Thus, I think, on the desktop, .NET (or a similar system like JAVA) is
the way to go on the long run.

There are definite advantages for a platform that one can build
applications on that is independent of the OS. However I don't think that
.NET will truly provide that. JAVA can but Microsoft allows direct
Windows API calls to improve performance and that destroys the ability for
an application that uses this to be cross platform runnable.
There are also real concerns about Microsoft's software patents and
if and/or when they will use them.
You know when I was just starting out as a programmer, we use to call
p-code running against a runtime engine an "interpreted language." It
seems to me that .NET is a very old idea that is simply being extended (a
little) by Microsoft. And btw like all interpreters I would be willing to
bet that .NET code will run slower than native code.
 

Re:Re: K questions

Quote
JAVA can but Microsoft allows direct
Windows API calls to improve performance and that destroys the ability for
an application that uses this to be cross platform runnable.
Microsoft compilers will supposedly do this without allowing the
programmer to avoid it. But A Delphi programmer should be able to
control the behavior of the compiler in that he can have it not create
platform dependent code (that might be running slower on a specific
platform compared to platform dependent code).
Quote

There are also real concerns about Microsoft's software patents and
if and/or when they will use them.

I am not a lawyer, of course .
Quote
You know when I was just starting out as a programmer, we use to call
p-code running against a runtime engine an "interpreted language." It
seems to me that .NET is a very old idea that is simply being extended (a
little) by Microsoft.
P-code was designed with interpreting in mind and "just in time
compilers" extended the idea to more performance. CIL (though of course
inspired by the p-code idea) was designed with on-site compilation in
mind and with the concepts and structures of Delphi in mind (a former
Borland guy was greatly involved). So I suppose it's a step ahead
regarding p-code.
Quote
And btw like all interpreters I would be willing to
bet that .NET code will run slower than native code.
Why should it ? Not because of the CIL (similar to p-code) layer. That
is just an intermediate compiler file. Breaking up the compiler into two
separate programs would not harm the running speed of the final machine
code. Of course other issues might restrict the optimization and thus
slow things down. But that is trading functionality against speed. (Do
you remember how fast DOS programs were regarding relative hardware
performance vs. today). Of course you are on the loosing side if you
don't need the new functionality offered.
-Michael
 

Re:Re: K questions

Quote
Introducing Mono/.Net means abandonning a true Pascal framework.
What do you mean by "a true Pascal framework" ?
There seems to be no language (created before c#) that is closer to .NET
than Delphi (because .NET/C# was strongly influenced by the guy who
designed Delphi for Borland and was hired by MS).
Quote
IMO, if they go this road, they'll be too late because of Lazarus, and it
will have been a waste of time and lost of market opportunity.

It would be GREAT if Lazarus would be an alternative creating native
code on Linux, if this is desired for whatever reason (e.g. for
low-resource embedded designs even if Delphi/MONO/Linux would work
perfectly together some day). But I fear it will still take a lot of
time until it's really usable.
-Michael
 

Re:Re: K questions

Hi!
Quote
>But support for native code is far from irrelevant. .NET is "not"
>a replacement for it.
>
Why not ?
Think of it this way. Even today. About 50 years after the first
computers there are still applications where you have to use assembler.
Of course the compilers pushed out the assembler programming,
but some parts are still done in assembly today.
All key parts of games and OS's are written in assembler.
The key reason to for .NET is to lower to cost of application development
and increase software security in general.
In that sense, you might see the following:
1.) Commercial apps done in native windows code.
2.) In-house applications and buisness logic applications
done in .NET
3.) A mix of both. Namely. Although today people use
compilers in general they still resort to assembly for some
parts of the application. In the same manner people
will start using .NET in general and sometimes resort
to native code and in some cases even to assembler.
The problem with the .NET today is that:
- is so slow that simply does not allow you
to address many applications even if you try
to improve its performance with non native code.
Speed of Borland Delphi 8 IDE is sad proof of that.
- brings no real benefits to a large pool of
programmers and application users.
Regards!
Atmapuri