Peace between Native and .NET freaks (a proposal)
Kostya
Why can't borland do something like this with Delphi?
It could make the best of both worlds. Otherwise
I think Delphi would be delegated to a role of
former VB. Use it to write something like
database front ends and that is it.
<quote>
# The best performance of generated IL code because of both
optimizations of the generated IL and less IL generated (as discussed in
the previous section). This is specifically because MC++ is the only
.NET compiler with a full optimizer back end, which is pretty much the
same one that is used by the unmanaged compiler.
# MC++ is your language of choice if you want full control of the .NET
environment:
* Allows one to use all seven levels of CTS member access. C#
allows only six.
* Allows direct access to interior gc pointers, useful in a whole
class of system applications such as system and .NET utilities.
* Offers explicit control of expensive operations like boxing.
* Supports multiple indexed properties on a type, unlike C#.
# MC++ is currently the only managed language that allows you to mix
unmanaged and managed code, even in the same file. This leads to several
other points:
* Allows a developer to keep performance-critical portions of the
code in native code.
* Gives seamless access to all unmanaged libraries, such as DLLs,
statically-linked libraries, COM objects, template libraries, and more.
* Leverages existing investments in C++ programming skills and
legacy C++ code.
* Porting unmanaged code to .NET: MC++ allows you to take existing
unmanaged code and compile it to managed code (with the /clr compiler
switch and IJW).
* Gives the ability to port code at one's own rate rather than
re-write all at once.
* Provides the easiest way to add .NET support to your existing
native C++ Windows applications, by allowing you to bridge the gap
between the two environments with as little work on your behalf as
possible, and with the lowest performance penalty.
# MC++ is currently the only language that allows some form of
multi-paradigm design and development with full support for generic
programming and templates. This can lead to more options and better
designs and implementations.
</quote>
Kostya
Atmapuri
Hear, hear...
An opportunity lost is lost. The damage has been done,
even if Borland does try to fix what was broken:
- VCL could have remained 100% W32 and improved.
- No need for VCL.NET and no new bugs and slow downs.
- continuity of the component and tools market.
What you port to .NET takes terrible penalty anyway
and it is done only to take advantage of some other
.NET features.
Regards!
Atmapuri
Abdullah Kauchali
> http://www.ondotnet.com/pub/a/dotnet/2003/01/13/intromcpp.html
>
> Why can't borland do something like this with Delphi?
> It could make the best of both worlds.
I'm guessing: because they'll need the same compiler that makes the
.NET framework itself? Something like asking Borland to give away their
own compiler?
From what it sounds like, MC++ will be the only tool to accomplish
the sort of tasks listed with intimate knowledge of how .NET works under
the hood. The only company that you'd want to trust when the "Covenant
of Safe & Managed Code" is to be broken, is the company that stipulates
the rules of the game in the first place viz. Microsoft.
Kostya
> the sort of tasks listed with intimate knowledge of how .NET works under
> the hood. The only company that you'd want to trust when the "Covenant
> of Safe & Managed Code" is to be broken, is the company that stipulates
> the rules of the game in the first place viz. Microsoft.
As for as I remember Borland and MS used to have some licensing deals.
May be it is possible for Borland to license parts from MS
that are needed to achieve the functionality?
Kostya
Cruxy
> Peace between Native and .NET freaks (a proposal)
It can't happen. The only thing would be quiet acceptance, but only if
the native API is not killed in Longhorn and later releases.
- Why should someone want to port something to .NET? Where's the
reason?
- Why should a developer accept an additional layer containing bugs
between the system and the app?
- Where is the reason to change the API at all?
(oh, yes I know: M$ only needs to maintain one code base for MAC-OS and
Windows. If they wants to (if Linux becomes relevant to them), they'll
also write an own .NET API for Linux to sell their office products. MS
does not need to use Java (they don't like it, cause it's from Sun). )
Tell me one real reason why anyone NEEDS .NET. I'm only interested in
the NEED for it. Whats in there that could not be implemented in Native
API? I don't see it & I tried. Tell me. Please.
--
cruxyATcruxyDOTnet
XanaNews 1.17.1.2
Jim Cooper
> - Why should someone want to port something to .NET? Where's the
> reason?
To take advantage of something that was only available in .NET (or
possibly preparing for that).
To futureproof their code.
To make code available on another platform supporting .NET (eg the CF)
To make code available to an ASP.NET application
> - Why should a developer accept an additional layer containing bugs
> between the system and the app?
Like the VCL, you mean? :-)
> - Where is the reason to change the API at all?
Coz it's crap
> (oh, yes I know: M$ only needs to maintain one code base for MAC-OS and
> Windows.
And exactly how will .NET help there?
> Whats in there that could not be implemented in Native API?
Right now with released MS stuff, nothing. In the future we're assured
that will change.
I wouldn't recommend anyone port anything to .NET without a good reason.
The same way any major changes to your code should be considered carefully.
Cheers,
Jim Cooper
_______________________________________________
Jim Cooper j...@falafelsoft.com
Falafel Software http://www.falafelsoft.com
_______________________________________________
Mauro Venturini
1 - Google for "Miguel de Icaza .NET"
2 - Read some of his articles, papers, interviews, etc.
"Cruxy" <m...@privacy.net> wrote in message
news:41ee39f3$1...@newsgroups.borland.com...
Chris Brooksbank
> between the system and the app?
Like the VCL, you mean? :-)
Excellent come back ! Why this guy using Delphi when he could be writing
assembler ?
somebody
> Tell me one real reason why anyone NEEDS .NET. I'm only interested in
> the NEED for it. Whats in there that could not be implemented in Native
> API? I don't see it & I tried. Tell me. Please.
Good question. It becomes more striking when you explicitly direct it to the
customer (user), not the developer (after all, it's them who pay the bills):
What advantage does a .net written application bring to the user (of desktop
apps)? Why should a user prefer a .net application over a w32 (or w64) one?
OK, I agree that on the server side java or .net do have advantages and
since the developer/provider makes the call, the situation is different. But
for the foreseable future, server side computing isn't going to replace
desktop computing. In fact, I don't expect a radical change in the balance
from what it is now.
You can ask the same question in terms of Java (from which we have more
historical lessons learned):
What advantage does a Java written application bring to the user (of desktop
apps)? Why should a user prefer a Java application over a native one?
Abdullah Kauchali
> What advantage does a Java written application bring to the user (of desktop
> apps)? Why should a user prefer a Java application over a native one?
Platform independence. Your move! :)
Bruce McGee
> http://www.ondotnet.com/pub/a/dotnet/2003/01/13/intromcpp.html
>
> Why can't borland do something like this with Delphi?
> It could make the best of both worlds. Otherwise
> I think Delphi would be delegated to a role of
> former VB. Use it to write something like
> database front ends and that is it.
[...]
Delphi offers unmanaged exports. You can't have managed and unmanaged
code in the same unit, but it lets a Delphi for .Net assembly expose
methods that can be called from any Win32 app without using COM
interop. It's one of my favourite new Delphi features. It's a feature
of .Net that C# doesn't even offer support for. I think it was
actually written for managed C++.
http://cc.borland.com/codecentral/ccweb.exe/listing?id=22688
http://cc.borland.com/codecentral/ccweb.exe/listing?id=22159
Delphi also supports a dynamic PInvoke, which is like unmanaged
exports, but in reverse. I haven't used this.
I'm not sure how I feel about the idea of mixed mode Delphi working the
same way C++ does or will. I'm open to being convinced either way as
long as there is still the option to write Win32 code that doesn't
require the .Net runtime to deploy.
--
Regards,
Bruce McGee
Glooscap Software
![Rudy Velthuis [TeamB]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWU6JIYTx6kJCxK1P9qy-0IkTLb3QUOOaGRszn1aPNSjVyUm9M=s40-c)
Rudy Velthuis [TeamB]
> http://www.ondotnet.com/pub/a/dotnet/2003/01/13/intromcpp.html
>
> Why can't borland do something like this with Delphi?
Borland is doing something like it already, in Delphi.
But MC++ is almost outdated. C++/CLI will be its better successor. It
is just as optimized, but at least offers real C++ syntax and
semantics, not the millions of __this and __that extensions. After all,
the full name is "Managed Extensions for C++".
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"In the End, we will remember not the words of our enemies, but the
silence of our friends."
- Martin Luther King Jr. (1929-1968)
Rudy Velthuis [TeamB]
> Hi!
>
> Hear, hear...
>
> An opportunity lost is lost. The damage has been done,
> even if Borland does try to fix what was broken:
>
> - VCL could have remained 100% W32 and improved.
No, it couldn't. Code like that will not run if the user doesn't have
proper rights, etc. Such programs are no full ".NET citizens".
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Lohr's Law: The future is merely the past with a twist — and better
tools." -- Steve Lohr
Abdullah Kauchali
> Borland is doing something like it already, in Delphi.
Rudy, can this be done with Delphi:
"To this point, MC++ is the only language where you can mix managed
(.NET) code and unmanaged code in the same assembly, and even in the
same source file." ?
Rudy Velthuis [TeamB]
No. But if you mix managed with unmanaged code, it will not run in
quite a few environments. MC++ is the only language, currently. But
Delphi can easily connect with unmanaged code in other assemblies.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Give me chastity and continence, but not yet."
-- Saint Augustine (354-430)
Abdullah Kauchali
> No. But if you mix managed with unmanaged code, it will not run in
> quite a few environments. MC++ is the only language, currently. But
> Delphi can easily connect with unmanaged code in other assemblies.
Yes, through standard interop. But that's *exactly* what this compiler
(library) is avoiding.
Can you please correct me if I am wrong?
Rudy Velthuis [TeamB]
> Rudy Velthuis [TeamB] wrote:
>
> > No. But if you mix managed with unmanaged code, it will not run in
> > quite a few environments. MC++ is the only language, currently. But
> > Delphi can easily connect with unmanaged code in other assemblies.
>
> Yes, through standard interop. But that's exactly what this compiler
> (library) is avoiding.
Delphi can for instance export code from a library project, and this
can immediately be used from Win32. Note that this must be declared as
unsafe code.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"I begin by taking. I shall find scholars later to demonstrate my
perfect
right."
-- Frederick (II) the Great
Atmapuri
> > An opportunity lost is lost. The damage has been done,
> > even if Borland does try to fix what was broken:
> >
> > - VCL could have remained 100% W32 and improved.
>
> No, it couldn't. Code like that will not run if the user doesn't have
> proper rights, etc. Such programs are no full ".NET citizens".
It would not run on internet Servers, which have those restrictions.
It would run everywhere else. All desktop computers and local
networks.
I understand the need for this capability (100% .NET app), but
not at the cost of automatically excluding everything else.
If there are 10% of apps that need this feature Ok, but why do all
the other have to follow regardless of the cost and drawbacks?
Regards!
Atmapuri.
Atmapuri
> Delphi offers unmanaged exports. You can't have managed and unmanaged
> Delphi also supports a dynamic PInvoke, which is like unmanaged
I think that is something that should be worked on so that
you could at least have units that are either W32 or .NET
in the same project. That would be perfectly sufficient, if
the interop would be done in the most efficient possible way.
(without COM).
Regards!
Atmapuri.
Abdullah Kauchali
> Delphi can for instance export code from a library project, and this
> can immediately be used from Win32. Note that this must be declared as
> unsafe code.
LOL.
That is not what I asked. :)
Can we please admit that what you are describing isn't *anything* like
what Kostya asked about?
Rudy Velthuis [TeamB]
> Can we please admit that what you are describing isn't anything like
> what Kostya asked about?
Yes, like I already said, MC++ is the only language allowing this.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"They couldn't hit an elephant at this dist--" - John B. Sedwick,
general, dying words, 1864
Abdullah Kauchali
> Yes, like I already said, MC++ is the only language allowing this.
Thank you. To reiterate:
Borland is *NOT* doing something like it already, in Delphi.
Rudy Velthuis [TeamB]
> Rudy Velthuis [TeamB] wrote:
>
> > Yes, like I already said, MC++ is the only language allowing this.
>
> Thank you. To reiterate:
>
> Borland is NOT doing something like it already, in Delphi.
Something _like_ it all right. Just not the same.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Java: the elegant simplicity of C++ and the blazing speed of
Smalltalk." -- Roland Turner
Bruce McGee
> Thank you. To reiterate:
>
> Borland is NOT doing something like it already, in Delphi.
OK, so what's your point?
Borland isn't doing exactly the same thing, but offers something
similar that I think is equally useful. One of the things I like about
this approach is that the .Net assembly can be loaded dynamically, so
at least part of the project will still run on systems that don't have
.Net installed. For example:
http://cc.borland.com/codecentral/ccWeb.exe/listing?id=22159
Abdullah Kauchali
> No.
LOL.
Abdullah Kauchali
> Something _like_ it all right. Just not the same.
Did you ever play-act as the Cheshire Cat at school? <g>
Bruce McGee
> I think that is something that should be worked on so that
> you could at least have units that are either W32 or .NET
> in the same project. That would be perfectly sufficient, if
> the interop would be done in the most efficient possible way.
> (without COM).
>
> Regards!
> Atmapuri.
So what will this gain you? I'm not against the idea. I just need to
understand how it would work to my advantage.
For example, I already have Delphi for Win32 and Delphi for .Net
projects that share common source code.
I suppose it could be less cumbersome than having separate Win32 and
.Net projects and using PInvoke/unmanaged exports to communicate back
and forth. Having Delphi take care of the communication back and forth
might also be more efficient than the way I do it.
What do you think?
Rudy Velthuis [TeamB]
> Rudy Velthuis [TeamB] wrote:
> > Something like it all right. Just not the same.
>
> Did you ever play-act as the Cheshire Cat at school? <g>
No.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"What do you take me for, an idiot?"
-- General Charles de Gaulle (1890-1970), when a journalist asked him
if
he was happy
Abdullah Kauchali
> OK, so what's your point?
That it is nowhere *near* what Borland is doing with Delphi.
> Borland isn't doing exactly the same thing, but offers something
> similar that I think is equally useful. One of the things I like about
> this approach is that the .Net assembly can be loaded dynamically, so
> at least part of the project will still run on systems that don't have
> .Net installed. For example:
>
> http://cc.borland.com/codecentral/ccWeb.exe/listing?id=22159
If you read the OP's link to the article you'll notice that
the author specifically talks about features of MC++ that go
well beyond just standard .NET to native interop capabilities -
like manipulating the internal .NET garbage collection pointer
stack.
We are *not* talking about *default* .NET capabilities of Delphi for
.NET. That, Bruce, is the point.
Bruce McGee
> We are not talking about default .NET capabilities of Delphi for
> .NET. That, Bruce, is the point.
I thought your point was to score some minor semantic point at Rudy's
expense.
You're right. Borland is not doing exactly what managed C++ will do
according to the article.
So, do you think adding some of these features to Delphi would be a
good idea? Which ones? I'd be curious to hear thoughts on the idea.
If they wind up being useful to me, I'd like to see them in Delphi,
because the chances that I'll move to C++ are slim.
Abdullah Kauchali
> I thought your point was to score some minor semantic point at Rudy's
> expense.
I hope I didn't make you unhappy too? :)
At Rudy's expense? LOL. Excuse me sir. I would not consider
clarifying a factually misleading statement about Borland
products to be minor semantic issues.
Judging from the liberal leap of imagination that Mr Velthuis had taken,
I would consider the misrepresentation a serious one.
> You're right.
I know.
> So, do you think adding some of these features to Delphi would be a
> good idea? Which ones?
I don't think so, no.
> I'd be curious to hear thoughts on the idea.
> If they wind up being useful to me, I'd like to see them in Delphi,
> because the chances that I'll move to C++ are slim.
Hence, irrelevant.
David Farrell-Garcia
> http://www.ondotnet.com/pub/a/dotnet/2003/01/13/intromcpp.html
>
> Why can't borland do something like this with Delphi?
IIRC, Borland said something about including C++ in a future version of
BDS. If that is correct it could prove interesting for some.
--
David Farrell-Garcia
Whidbey Island Software LLC
Posted with XanaNews 1.17.1.2
Steve Garland
Why can't borland do something like this with Delphi?
>>
Managed C++ died, MS introduced new C++/CLI platform:
http://www.codeproject.com/managedcpp/cppcliintro01.asp
--
Steve Garland sgar...@astatech.com
SkyWire Video - Cross Platform MPEG4 Video Streaming
SkyWire Video GPS- Location Based Integration of Video and Remote Devices
SkyWire VoIP - Convergence of IP and Telephone Systems- Win32 and PocketPC
ASTA Technology Group www.astatech.com www.astaskywire.com
Kostya
> http://www.codeproject.com/managedcpp/cppcliintro01.asp
That is fine, now it has nicer syntax but the essence of
what it does remains the same (much improved though)- nice
interop between native/cli code both ways, ability to do
deterministic memory management, compile time optimization
etc. etc. All inside single project using the same language.
This is what I want. If MS offers it and Borland does
not then Delphi looks a second rate tool relegated to
the role of former VB.
Kostya
Brent S.
"Chris Brooksbank" <NoSpamPlease@Somewhere> wrote in message
news:41ee...@newsgroups.borland.com...
> > - Why should a developer accept an additional layer containing bugs
> > between the system and the app?
>
> Like the VCL, you mean? :-)
>
> Excellent come back ! Why this guy using Delphi when he could be writing
> assembler ?
>
The VCL is natively compiled and you have its full source code. The VCL
does not sit between the system and the app. .NET is a black box, destined
to change many times. I don't know how you could think this was an
excellent come back at all.
At least with Delphi you can predict what code will be created and optimize
just as if you were writing in assembler, so I don't get your question.
Brent S.
Kostya
I can leave with being forced to .NET
if it does not impede the power. It
seems like VS2005 C++ kinda heading
that way. I see no reason why Borland
should not.
Kostya
Brent S.
"Jim Cooper" <j...@falafelsoft.com> wrote in message
news:41ee3e7b$1...@newsgroups.borland.com...
>
> > - Why should someone want to port something to .NET? Where's the
> > reason?
>
> To take advantage of something that was only available in .NET
I can't imagine anything which will be available only in .NET.
> (or possibly preparing for that).
So you admit there is nothing now?
> To futureproof their code.
.NET will only be the future if it is widely accepted. It will be accepted
only if they don't upset all of thier customers. Their customers(developers
are customers too) will only be happy with backward compatability, fast
execution, and a lack of stringent OS requirements.
.NET has no compelling benefits for customers who are not developers.
Marketing cannot make up the gap.
> To make code available on another platform supporting .NET (eg the CF)
I'll believe it when I see it. MS wants to sell MS operating systems.
> To make code available to an ASP.NET application
Ok... Good point. This is .NETs place.
>
> > - Why should a developer accept an additional layer containing bugs
> > between the system and the app?
>
> Like the VCL, you mean? :-)
The VCL is not a layer, and you have the source. Not exactly the same thing
is it?
>
> > - Where is the reason to change the API at all?
>
> Coz it's crap
Ok. Change the API... (no one really cares apart from customers demanding
backward compatability) Its not the API that I care about, but the ability
to sidestep all of the .NET garbage and continue to write native code, and
see what it compiles to.
>
> > (oh, yes I know: M$ only needs to maintain one code base for MAC-OS and
> > Windows.
>
> And exactly how will .NET help there?
You said above: " To make code available on another platform supporting
.NET"
Your right though, .NET won't help you.
>
> > Whats in there that could not be implemented in Native API?
>
> Right now with released MS stuff, nothing. In the future we're assured
> that will change.
Yes... Nothing... and since MS has to buy innovation now days a lot of it
will have to be ported after they buy it. Innovation will continue in and
out of .NET.
>
> I wouldn't recommend anyone port anything to .NET without a good reason.
Still waiting for the reason.
Your argument in a nutshell:
1. .NET will be worth developing for because one day they will have neat
stuff that is only in .NET.
2. .NET is the future because MS says so.
3. We might get platform portability.
4. ASP.NET is cool.
</argument>
3 out of 4 are promises/threats (2 is a threat). ASP.NET is cool.
So for today only (4) is true.
Brent S.
Dennis Landi
news:41ee9d20$1...@newsgroups.borland.com...
There is no way delphi could head that way without a 64-bit native
compiler...
Without it, they are so far behind VC++ it ain't funny... (You can't have
interop without having both sides of the coin to inter-op with...) You
won't be seeing interop between 64-bit D.NET and 32-bit native Delphi.
We've already been told by the MS engineers it can't be done. (I've posted
the quotes from the VC++ forum a long time ago).
-d
Kostya
> compiler...
That is pretty obvious
Kostya
Larry Drews
news:41eea41d$1...@newsgroups.borland.com:
>
> Without it, they are so far behind VC++ it ain't funny...
>
>
I guess there is no hope that SQL could compete either, huh?
Joanna Carter (TeamB)
41ee9b0d$1...@newsgroups.borland.com...
> The VCL is natively compiled and you have its full source code. The VCL
> does not sit between the system and the app. .NET is a black box,
destined
> to change many times.
.NET is not a black box. Take any of the assemblies shipped and run them
through Reflector, you will see the code used to create the asemblies. M$
have not obfuscated their assemblies so that you can see how they are made.
> At least with Delphi you can predict what code will be created and
optimize
> just as if you were writing in assembler, so I don't get your question.
With .NET the code is optimised for the appropriate CPU/instruction set
dependent on the machine on which it is installed.
Joanna
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
Brent S.
"Joanna Carter (TeamB)" <joa...@nospam.co.uk> wrote in message
news:41eebb55$1...@newsgroups.borland.com...
> "Brent S." <brentatatmosoftdotcom> a écrit dans le message de news:
> 41ee9b0d$1...@newsgroups.borland.com...
>
> dependent on the machine on which it is installed.
>
Optimized, or not optimized, I don't know. I'm sure there will be a better
level of optimization on some CPUs than others, and in some OS's more than
others (if they ever get it on another platform). While I agree that JIT
compiling is a neat feature, I don't need it. I want to see what the
compiler did before my software ships, and be responsible for its
performance. With .NET, I don't know which compiler will be used where, or
know what it is likely to do with my code. How often are they going to
release new versions? Who is to say that a future version won't break
something? Multiplicity of target architectures will only aggravate the
situation.
Brent S.
Jim Cooper
> The VCL does not sit between the system and the app.
Are you talking about the same VCL? What do you think it does sit between?
Cheers,
Jim Cooper
_______________________________________________
Jim Cooper j...@falafelsoft.com
Falafel Software http://www.falafelsoft.com
_______________________________________________
Abdullah Kauchali
> Are you talking about the same VCL? What do you think it does sit between?
LOL
Jim Cooper
> I can't imagine anything which will be available only in .NET.
We've moved beyond this point some time ago :-) Whether you can imagine
it or not is beside the point, it will still happen, according to MS.
You can choose not to believe them, but it there OS and their API...
> So you admit there is nothing now?
I have never claimed there is something now. AFAIK that won't be an
issue until Longhorn at the earliest. I've said many times there is no
need to panic about this :-) Future proofing is a reason to move to
.NET, but IMO it is not especially urgent.
> .NET has no compelling benefits for customers who are not developers.
No, I keep making that point myself. This is an issue for developers,
not end-users (not directly anyway), by and large.
> Marketing cannot make up the gap.
MS marketing still don't know what .NET is - this is an issue of some
frustration for those MSers who do :-) There was a post a couple of days
ago about this.
> I'll believe it when I see it. MS wants to sell MS operating systems.
Sorry, I didn't mean to give the impression that I was talking about
non-MS OSes. But the CF runs on different hardware platforms.
> The VCL is not a layer
Excuse me, but the VCL **is** a layer. If it isn't I have no idea what
you might think a layer is.
> and you have the source.
You can get the source for most of the FCL too (you do not have the
complete VCL source either). You can also use Reflector on anything not
obfuscated (you can use it then too, but it's not much fun)
> Not exactly the same thing is it?
Yes. Library calls are library calls. The performance hits in .NET are
down to the jitter, gc and so on.
> continue to write native code, and see what it compiles to.
I've never had the slightest interest in seeing what a language compiles
to. That's the point of using a high-level language, after all. But
then, I've always been more interested in the problem-solving side of
things.
> Still waiting for the reason.
Then don't change. That's the only sensible course for you.
> 1. .NET will be worth developing for because one day they will have neat
> stuff that is only in .NET.
> 2. .NET is the future because MS says so.
> 3. We might get platform portability.
> 4. ASP.NET is cool.
More or less. It's a list of reasons, though, not an argument.
> So for today only (4) is true.
No, 1, 2 and 3 are true too. 1 and 2 are not necessarily compelling
reasons to move *now* though. I use the CF for PocketPC work (ie point 3).
The tone of your reply seems to indicate you think I'm trying to
advocate everyone move to .NET. I'm not and I never have (read my
previous posts on the subject if you don't believe me). There is no
doubt that it will be very important in the near future, though. MS have
too much invested in it for it to be otherwise.
I have no problem with people not wanting to use it. I do have a problem
with the ill-informed diatribes that you often see here :-)
Eugen Neuber
> somebody wrote:
>> What advantage does a Java written application bring to the user (of
>> desktop apps)? Why should a user prefer a Java application over a native
>> one?
>
> Platform independence. Your move! :)
For desktop applications or for server applications ?
Rudy Velthuis [TeamB]
> Kostya wrote:
>
> > http://www.ondotnet.com/pub/a/dotnet/2003/01/13/intromcpp.html
> >
> > Why can't borland do something like this with Delphi?
>
> IIRC, Borland said something about including C++ in a future version
> of BDS. If that is correct it could prove interesting for some.
Yes, but, although I don't know this, I'd expect to see something like
C++Builder, for Win32.
I don't think they'll include Managed C++ or C++/CLI (for .NET), since
these are not their compilers.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Humor is just another defense against the universe."
-- Mel Brooks (1926- )
Rudy Velthuis [TeamB]
> Abdullah Kauchali wrote:
>
> > Thank you. To reiterate:
> >
> > Borland is NOT doing something like it already, in Delphi.
>
> OK, so what's your point?
>
> Borland isn't doing exactly the same thing, but offers something
> similar that I think is equally useful.
That is what I meant as well. Not the same, but something like it.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"I don't feel good."
- The last words of Luther Burbank (1849-1926)
Rudy Velthuis [TeamB]
> I want to see what the compiler did before my software ships, and be
> responsible for its performance.
Then use NGEN (which precompiles to native code) and a debugger. <g>
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Everything that can be invented has been invented."
-- Charles H. Duell, Commissioner, U.S. Office of Patents, 1899
Rudy Velthuis [TeamB]
> .NET is not a black box. Take any of the assemblies shipped and run
> them through Reflector, you will see the code used to create the
> asemblies.
Yes, indeed. You will onyl see a few "primitives", which can't be
disassembled. Large parts of the CLR are even available in source, as
part of the Rotor project, AFAIK.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Analyzing humor is like dissecting a frog. Few people are interested
and the frog dies of it." -- E. B. White (1899-1985)
Rudy Velthuis [TeamB]
> > Platform independence. Your move! :)
>
> For desktop applications or for server applications ?
Indeed. <g>
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Why was I with her? She reminds me of you. In fact, she reminds me
more of you than you do!" -- Groucho Marx
Rudy Velthuis [TeamB]
> <<http://www.ondotnet.com/pub/a/dotnet/2003/01/13/intromcpp.html
>
> Why can't borland do something like this with Delphi?
> > >
>
>
> Managed C++ died, MS introduced new C++/CLI platform:
> http://www.codeproject.com/managedcpp/cppcliintro01.asp
Yes, but from what I heard, C++/CLI is not finalized yet, and neither
is the C++/CLI standard.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Intellectuals solve problems; geniuses prevent them." -- Albert
Einstein
Abdullah Kauchali
> For desktop applications or for server applications ?
Either.
Abdullah Kauchali
> Indeed. <g>
Was it rhetorical? I didn't get it.
Abdullah Kauchali
> He said "for a or for b", and I replied "indeed", indicating it was
> indeed for a or for b. <g>
Oh ... :) ok.
Hey ... I'm off to bed ... take care and no offence about earlier! :)
Rudy Velthuis [TeamB]
He said "for a or for b", and I replied "indeed", indicating it was
indeed for a or for b. <g>
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Learning is what most adults will do for a living in the 21st century."
-- Perelman
Maxwell Smart
wrote:
Hey Jim..
I notice you completely (and conveniently) ignored the part of his
post in which he specifically asked for someone to give him a reason
why anyone NEEDS dot net.
And please don't fall back on some ridiculous "to future proof"
argument because that's pointless.
He wants to know why you NEED dot net.
Furthermore, I'll expand on his question:
Why did Microsoft feel they NEEDED to "invent" dot net? There
absolutely nothing wrong with Win32. Any programming task you could
imagine could be accomplished using Win32 programming. There was no
NEED for dot net.
If they wanted to expand/improve upon Win32, fine, but there was zero
reason to bring about some bloated, slow-as-hell "solution" which
turns out causes more problems than anything else.
Once again, why do you NEED dot net?
Kostya
> these are not their compilers.
They should include Delphi/CLI (for .NET) and be done with it.
If they are missing particular thechnology to provide the
same quality of interop as C++/CLI then they should license
it from MS.
Having done all that Borland would have a chance to compete
in .NET/win32/win64 land. Without it it is a second rate
stuff compared to what MS is going to do.
Kostya
Rudy Velthuis [TeamB]
> > I don't think they'll include Managed C++ or C++/CLI (for .NET),
> > since these are not their compilers.
>
> They should include Delphi/CLI (for .NET) and be done with it.
Delphi for .NET is Delphi/CLI. <g>
Actually, the unmanaged parts of Managed C++ (or C++/CLI) are actually
not conformant with the CLI (Common Language Interface).
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"The opposite of a correct statement is a false statement. The opposite
of a profound truth may well be another profound truth."
- Niels Bohr (1885-1962)
David Farrell-Garcia
> Yes, but, although I don't know this, I'd expect to see something like
> C++Builder, for Win32.
>
> I don't think they'll include Managed C++ or C++/CLI (for .NET), since
> these are not their compilers.
I think you are probably right. It would be much more likely.
--
David Farrell-Garcia
Whidbey Island Software LLC
Posted with XanaNews 1.17.1.2
Rudy Velthuis [TeamB]
> Actually, the unmanaged parts of Managed C++ (or C++/CLI) are actually
> not conformant with the CLI (Common Language Interface).
Actually, that was actually one actually too many. <g>
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"I do not fear computers. I fear the lack of them." -- Isaac Asimov.
Kostya
No reasons other then MS playing their
tricks with Sun, DRM, code control,
etc, etc.
They did provide nice looking class library
but the price to pay for that seems to be high.
Also they did protect their own butt
adding C++/CLI to VS2005 so they can
squeeze all the performance they need
in a nice way.
I wonder if Intel's own compiler in the
future could be plugged there for native
parts. In some cases it does provide big
boost in performance.
Kostya
Kostya
>
> Actually, the unmanaged parts of Managed C++ (or C++/CLI) are actually
> not conformant with the CLI (Common Language Interface).
No it is not. I do not care how you call it and what's the right
terminology but Delphi does not come close to the interop level
provided by C++ in VS2005. No 64bit part either.
In reality I think it'll take at least few years until .NET
will become mainstream. So may be Borland still have a chance
to do it right. D2005 looks like a kinda flop. We'll see
if Borland will once again do what made its reputation in
a first place.
Kosty
Cruxy
Java. The big difference between Java and .Net is the availability for
other platforms. Java makes sence, cause you could use your code on
*lots more* OS's.
--
cruxyATcruxyDOTnet
XanaNews 1.17.1.2
Cruxy
> But there was a need for a counter-product for Java. When MS realized
> they couldn't "embrace and extend" Java, they invented their own
> framework and swiftly provisioned for DRM and the like, just in case.
> And "managed code" in conjunction with a single controlling entity
> gives me goose pimples...
agreed.
--
cruxyATcruxyDOTnet
XanaNews 1.17.1.2
Cruxy
> > The VCL does not sit between the system and the app.
>
> Are you talking about the same VCL? What do you think it does sit
> between?
You have the free choice to not use it. If you want to use pure API,
you could.
--
cruxyATcruxyDOTnet
XanaNews 1.17.1.2
Cruxy
> To take advantage of something that was only available in .NET (or
> possibly preparing for that). To futureproof their code.
MS will never break the API. Look for the calls since Win 3.11 ;-)!
> To make code available on another platform supporting .NET (eg the CF)
O.K. that will be MAC & Windows? Oh yes there also is a Linux Project.
> To make code available to an ASP.NET application
Why use that 100% unportable platformdependant code?
> Like the VCL, you mean? :-)
Definitely not. The VCL is no real layer between the App and the
System, cause you could control it. You even could do your own compile
of VCL (as long as you do not use it as runtime-package) - and I don't
use packages at all.
> Coz it's crap
Why? I tell you that .Net is crap. That's no answer.
> And exactly how will .NET help there?
If MS Office/IE is done in .Net, they'll have one .Net Code for Win &
MAC. AFAIK it's at least planned to do that.
> Right now with released MS stuff, nothing. In the future we're
> assured that will change.
Maybe. It'll depend on the acceptance of .Net.
> I wouldn't recommend anyone port anything to .NET without a good
> reason. The same way any major changes to your code should be
> considered carefully.
I still search any reason. The only thing I read here was the thing
with ASP.Net (Which I won't use & don't need).
--
cruxyATcruxyDOTnet
XanaNews 1.17.1.2
Abdullah Kauchali
> What I forgot:
>
> Java. The big difference between Java and .Net is the availability for
> other platforms. Java makes sence, cause you could use your code on
> *lots more* OS's.
>
Bingo. I would then settle for a .NET Client using web services talking
to a J2EE backend. That's settled, can we all stop bickering now? :)
Cruxy
> This thread is a reason why "Peace between Native and .NET
> freaks" will not happen.
Correction:
This thread shows why "Peace between Native and .NET freaks"
will not happen.
--
cruxyATcruxyDOTnet
XanaNews 1.17.1.2
Cruxy
>
> Bingo. I would then settle for a .NET Client using web services
> talking to a J2EE backend. That's settled, can we all stop bickering
> now? :)
;-)! This thread is a reason why "Peace between Native and .NET freaks"
will not happen.
(I've no problem, I don't like .Net - No chance. I won't write programs
for it.)
--
cruxyATcruxyDOTnet
XanaNews 1.17.1.2
Abdullah Kauchali
> Correction:
> This thread shows why "Peace between Native and .NET freaks"
> will not happen.
I just proposed a viable solution! It's on the table. Look, we can
negotiate like this:
Phase 1 - Write J2EE backend and Win32 client (everyone's happy);
Phase 2 - Leave J2EE backend and convert Win32 to .NET Client (you
*will* be made to be happy);
Phase 3- Leave J2EE backend and convert the .NET client to Swing client
(once your spirit is broken because of Phase 2, Abu Ghraib style, you
will accept anything!)
That's plan. No?
Abdullah Kauchali
> But there was a need for a counter-product for Java. When MS realized they
> couldn't "embrace and extend" Java, they invented their own framework and
> swiftly provisioned for DRM and the like, just in case. And "managed code"
> in conjunction with a single controlling entity gives me goose pimples...
(allow me to finish)
... the size of Mount Kilimanjaro!
Jim Cooper
> MS will never break the API.
That's not what I said. Future API calls will be .NET only (see posts
from Euan on this topic)
> O.K. that will be MAC & Windows? Oh yes there also is a Linux Project.
No, I meant other hardware platforms running an MS OS. MS are definitely
not big supporters of porting code to non-MS operating systems :-)
> Why use that 100% unportable platformdependant code?
Why not?
> Definitely not. The VCL is no real layer between the App and the
> System, cause you could control it.
You're incorrect on that count. You may prefer it as a layer, but it is
a layer nonetheless.
> Why?
Why is the current Windows API crap? You think it's nice? Try writing
directly with it.
> If MS Office/IE is done in .Net, they'll have one .Net Code for Win &
> MAC. AFAIK it's at least planned to do that.
You know wrong. The MS people I talked to are extremely keen to **not**
push .NET as a cross-platform (to non-MS OSes) solution.
> I still search any reason.
Then don't change.
Cheers,
Jim Cooper
_______________________________________________
Jim Cooper j...@falafelsoft.com
Falafel Software http://www.falafelsoft.com
_______________________________________________
Jim Cooper
> You have the free choice to not use it. If you want to use pure API,
> you could.
You can make pure API calls in .NET too
Eric Grange
'Pure'? You mean you can bypass the P/Invoke
and marshalling stuff easily?
Eric
Jim Cooper
> 'Pure'? You mean you can bypass the P/Invoke
> and marshalling stuff easily?
No, I just meant you could write code that only made API calls. I was
assuming P/Invoke would be used. Sorry for the confusion.
Rudy Velthuis [TeamB]
> No it is not. I do not care how you call it and what's the right
> terminology but Delphi does not come close to the interop level
> provided by C++ in VS2005.
That interop level is NON-CLI. Delphi for .NET would deserve the name
more than C++/CLI. I do agree thsat the managed parts of C++/CLI are
conformant. But the parts you so greatly admire are NOT.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Sanity is a madness put to good uses."
- George Santayana (1863-1952)
Rudy Velthuis [TeamB]
> > Delphi for .NET is Delphi/CLI. <g>
> >
> > Actually, the unmanaged parts of Managed C++ (or C++/CLI) are
> > actually not conformant with the CLI (Common Language Interface).
>
> No it is not.
Yes, it is. Delphi is completely conform with the CLI. The umanaged
parts of C++/CLI are actually non-CLI. Only the managed parts are CLI
conform, and these are plain C++.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Far too many development shops are run by fools who succeed despite
their many failings." -- Brion L. Webster
Bruce McGee
to think any of these new C++ features would benefit Delphi.
Of course, YMMV.
--
Regards,
Bruce McGee
Glooscap Software
Kostya
> more than C++/CLI. I do agree thsat the managed parts of C++/CLI are
> conformant. But the parts you so greatly admire are NOT.
I do not give a rat about conformance, I only care about
results
Kostya
Rudy Velthuis [TeamB]
Yes, I noticed. Still, my statement stands: Delphi for .NET would
deserve the name Delphi/CLI much more than C++/CLI deserves its name.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Women should be obscene and not heard."
-- Groucho Marx
Bruce McGee
> I do not give a rat about conformance, I only care about
> results
>
> Kostya
I worked with a developer who thought like this. When he left, I wound
up adopting a bunch of his projects. To this day, when we get together
for lunch, I still swear at him. :)
Kostya
> up adopting a bunch of his projects. To this day, when we get together
> for lunch, I still swear at him. :)
What do you know about me? The applications I've written run in
hundreds of places 24x7. So keep you thought to yourself.
Also accordingly to your logic people that are
creating C++/CLI (yes that is how they call it
disregarding to what Rudy says) are junk programmers
and I doubt that is the case.
The last thing. I've meat enough people coming
from OOP courses, praying to Grady Booch and
doing all the design accordingly to what
Rational says. The problem was that most
of them have produced total crap.
Kostya
Joanna Carter (TeamB)
41ef...@newsgroups.borland.com...
> MS will never break the API. Look for the calls since Win 3.11 ;-)!
You were obviously not around when they changed the interfaces to the API
between Office 97 and Office 2000. That broke all sorts of code :-((
Joanna
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
Joanna Carter (TeamB)
41ef82fa$1...@newsgroups.borland.com...
> Why is the current Windows API crap? You think it's nice? Try writing
> directly with it.
Mmm, all those lovely message loops with 500 line case statements :-))
Andrew Rybenkov
does this look like 500 line case statement?
function WndProc(HWnd: HWND; Msg: UINT; wParam: WPARAM; lParam: LPARAM): LRESULT; stdcall;
var i: Integer;
begin
for i := Low(EventHandlers) to High(EventHandlers) do
if EventHandlers[i].msgID = msg then begin
Result := EventHandlers[i].onFunc(wParam,lParam);
Exit;
end;
Result := DefWindowProc(HWnd,Msg,WParam,LParam);
end;
--
Andrew Rybenkov.
Joanna Carter (TeamB)
41ef...@newsgroups.borland.com...
> does this look like 500 line case statement?
No, but it does involve a linear search; that could be even slower than the
case statement :-)
Andrew Rybenkov
> case statement :-)
a) that linear search has same time as case (actually less, as Intel CPU would predict
backward jumps in the cycle, while case involves upredictable forward jumps).
b) nobody prevents more or less skilled programmer to rearrange the message tables
(to sort or to hash) in AppInitialize routine, if there are lot of messages to process.
actually, many things became easier (or even possible) once you refuse from VCL doping.
--
Andrew Rybenkov.
Bruce McGee
> What do you know about me? The applications I've written run in
> hundreds of places 24x7. So keep you thought to yourself.
>
> Also accordingly to your logic people that are
> creating C++/CLI (yes that is how they call it
> disregarding to what Rudy says) are junk programmers
> and I doubt that is the case.
>
> The last thing. I've meat enough people coming
> from OOP courses, praying to Grady Booch and
> doing all the design accordingly to what
> Rational says. The problem was that most
> of them have produced total crap.
>
> Kostya
Wow. Dude, you need to think about adding more fibre to your diet.
I really don't care how good you think your code is, and I'm not
expressing any opinion on C++/CLI or .Net in general. I'm just writing
something I thought was funny about a friend I used to work with. Note
the smiley. His code was a mess, but at least he has a sense of humour.
Now, do you have any other instructions for me about what I can and
can't post?
Abdullah Kauchali
> Seems like a pretty minor point to me, especially since you don't seem
> to think any of these new C++ features would benefit Delphi.
Tinkering with the .NET framework directly (ie. straight into the belly
of the beast) as can be done with MC++ is always going to be a bad
idea *if* you don't have Microsoft's blessings. Bruce, do you think
Microsoft will/can grant Borland (or any company) the privilege of doing
exactly that? If the answer is no, they you see my point. If the
answer is yes, then you may well be right about me stressing about a
"minor point."
> Of course, YMMV.
Let's find out, shall we?
Rudy Velthuis [TeamB]
> in conjunction with a single controlling entity
Do you mean the .NET framework, or Microsoft?
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Reality is that which, when you stop believing in it, doesn't go away."
-- Philip K. Dick.
Rudy Velthuis [TeamB]
> > I do not give a rat about conformance, I only care about
> > results
>
> I worked with a developer who thought like this. When he left, I
> wound up adopting a bunch of his projects. To this day, when we get
> together for lunch, I still swear at him. :)
<g> I know what you mean.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"In this world, nothing is certain but death and taxes."
-- Benjamin Franklin.
Rudy Velthuis [TeamB]
> > I worked with a developer who thought like this. When he left, I
> > wound up adopting a bunch of his projects. To this day, when we
> > get together for lunch, I still swear at him. :)
>
> What do you know about me?
He talked about a guy he had worked with, not about you.
And even apps that run 24x7 are not necessarily easily maintainable by
someone else.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"When I told the people of Northern Ireland that I was an atheist, a
woman in the audience stood up and said, 'Yes, but is it the God of
the Catholics or the God of the Protestants in whom you don't
believe?" -- Quentin Crisp.
Rudy Velthuis [TeamB]
> Honestly, I don't know. In fact, I'm not sure Borland needs
> Microsoft's permission to do some of the same things.
I don't see why they would.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"The nationalist not only does not disapprove of atrocities committed
by his own side, but he has a remarkable capacity for not even hearing
about them" -- George Orwell
Bruce McGee
> Bruce McGee wrote:
> > Seems like a pretty minor point to me, especially since you don't
> > seem to think any of these new C++ features would benefit Delphi.
>
> Tinkering with the .NET framework directly (ie. straight into the
> belly of the beast) as can be done with MC++ is always going to be a
> bad idea if you don't have Microsoft's blessings. Bruce, do you think
> Microsoft will/can grant Borland (or any company) the privilege of
> doing exactly that? If the answer is no, they you see my point. If
> the answer is yes, then you may well be right about me stressing
> about a "minor point."
>
> > Of course, YMMV.
>
> Let's find out, shall we?
Honestly, I don't know. In fact, I'm not sure Borland needs
Microsoft's permission to do some of the same things.
I'm not sure what some of the advantages are, but would be curious to
learn more. The idea of tinkering with the internals makes me a little
nervous, though. Kind of like the ability to seriously shoot yourself
in the foot in an otherwise (supposedly) safe environment. :)
David Clegg
> To this day, when we get together
> for lunch, I still swear at him. :)
That reminds me. Now that I'm back in NZ I really must catch up with
the programmer who wrote the app I maintained at my last company. I
imagine I'd be doing pretty much the same thing. :-)
--
Cheers,
David Clegg
dcl...@gmail.com
Abdullah Kauchali
> Honestly, I don't know. In fact, I'm not sure Borland needs
> Microsoft's permission to do some of the same things.
It's not a matter of permission in as much as it is one of being
"privy" to the inner workings of the .NET engine (having access to
internal libraries, headers etc and all sorts of dirty secrets).
This compiler is the mother of all compilers vis-a-vis the morass of
Microsoft frameworks currently existing on Windows. And I think it will
be kept internally for exclusive usage by Microsoft, at least for a
while. Who knows?
> I'm not sure what some of the advantages are, but would be curious to
> learn more.
Read the article. It's mentioned there. Also search MSDN for more
info.
> The idea of tinkering with the internals makes me a little
> nervous,
As it should. That's my point. If it ain't official, it would not
be a good idea.
> though. Kind of like the ability to seriously shoot yourself
> in the foot in an otherwise (supposedly) safe environment. :)
Correct.
I earlier spoke about a lamentable absence of the notion of 100% pure
.NET applications (as used in the Java world). The idea of standard
interop as part & parcel of the core architecture and the presence of
compilers like MC++ make me believe that the concept of purity will
never prove to be anything useful other than for marketing purposes.
Rudy Velthuis [TeamB]
> It's not a matter of permission in as much as it is one of being
> "privy" to the inner workings of the .NET engine (having access to
> internal libraries, headers etc and all sorts of dirty secrets).
Er...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotne
t/html/mssharsourcecli.asp
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"They say such nice things about people at their funerals that it
makes me sad that I'm going to miss mine by just a few days."
-- Garrison Kielor.
Abdullah Kauchali
> Er...
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotne
> t/html/mssharsourcecli.asp
Er... what, Rudy? Did you even read your own link? LOL. Man, you are
a comedian. :)