Delphi Pages Forums  

Go Back   Delphi Pages Forums > Delphi Forum > .NET

Lost Password?

Thread Tools Display Modes
Old 06-21-2002, 09:14 PM
AREF AREF is offline
Senior Member
Join Date: Feb 2001
Posts: 285
Default Does Delphi Support .Net Technology?!

Hi there,

I feel we are losing lots of job opportunities because everything is going to solve into Microsoft's .Net technology! Like ASP.NET , VB.NET and so on. Now I wonder if Delphi supports .Net ? if not, does anyone know what to do?!


Reply With Quote
Old 06-21-2002, 09:51 PM
GoodFun GoodFun is offline
Senior Member
Join Date: Jan 2001
Posts: 2,645
Default RE: Does Delphi Support .Net Technology?!

Hi there...

Delphi 7 will fully support .NET as you can read in this post from Borland:

Hope this helps,


<cr>Please click on Accept if this helped...</cr>
Reply With Quote
Old 06-22-2002, 04:21 AM
Myst Myst is offline
Senior Member
Join Date: Feb 2002
Posts: 336
Default RE: Does Delphi Support .Net Technology?!

I'm not entirely sure, but i think delphi 6 enterprise mentioned it when i installed it??

-= Signature =-

If this helps, click the lil "accept as answer" link

If you aren't using ResHack to hack the resource then switch to it, cuz it was fully written in Delphi 3


--== MySt ==--
Reply With Quote
Old 06-22-2002, 06:39 AM
david.sims david.sims is offline
Senior Member
Join Date: May 2002
Posts: 256
Default RE: Does Delphi Support .Net Technology?!

There is support for .NET in Delphi, I'm not sure to what extent, but Microsoft admitted that Borland were the first to release a compatable product.

Reply With Quote
Old 06-22-2002, 08:26 AM
I.Ivanov I.Ivanov is offline
Senior Member
Join Date: Dec 2001
Posts: 166
Default RE: Does Delphi Support .Net Technology?!

There will be support of .Net in D7. But most software developers are migrating to c# now, as they does not want to wait and most likely this support will be not very good.

Here is some info from borland newsgroups:

" That Delphi feeling
Once you’ve bought into .Net, you start to wonder how Borland expects to prosper in a .Net world. (If you write books or components, you certainly hope that Delphi for .Net won’t be like Kylix, a niche of a niche, that only appeals to a small portion of the small Delphi market.) The short answer is that Borland thinks that in a world where all languages are essentially equal – where they all use the same runtime library, and they can all use new API’s without translation – they will be able to convince people that Delphi is the best development environment. I don’t know if they’ll be able to pull this off, but I’m very glad that they’re going to try, that they’re not willing to settle for just maintaining their existing market share.
In this vein, Chuck talked about what goes into the Delphi “feel.” I think there were three main points, here. Chuck emphasized that the component model is probably the single biggest part of the feel. It contributes to the “tactile” nature of Delphi programming – there’s something you can look at and touch, even for something abstract like a timer or a database connection – and most Delphi programmers are more “component oriented” than “object oriented”. In fact, Chuck said that you can be a “successful” Delphi programmer without ever using inheritance. He’s probably right: While some of the most ‘interesting’ parts of various projects have required inheritance, I’ve certainly done plenty of bread-and-butter apps where inheritance didn’t come in at all.
Somewhat more broadly, Chuck says that one of the most important questions to ask when comparing programming environments is “how many things do you have to remember?” The more things you have to remember, the easier it is to forget one and make a serious mistake. Delphi promotes a “contract-less programming” style that encourages you to freely mix components without having to worry overmuch about how they ‘ought’ to be used.
Finally, with Delphi you “Debug the code you wrote … and only the code you wrote.” Your code isn’t cluttered with lots of tool-generated code, as in C#. Despite some recent online discussions about how building a form with run-time code can be faster (less string lookup) and make for smaller executables (no need to link in unused property setters) than Delphi’s resource streams, Delphi will continue to use resource streams.
One thing that struck me about the ‘Delphi feel’ part of Chuck’s Moving Delphi talk was that Chuck might almost as well have been talking about Visual Basic. Chuck did talk a bit about the difference in the C and Pascal notion of types, but otherwise he didn’t say all that much about Pascal. Unfortunately, somehow it’s just as chic to disdain Pascal as it is to know Ruby or Python. I suspect Borland’s going to have a hard time increasing Delphi’s market share until Borland can find a way to tell the world what Delphi users all know – that Object Pascal is a wonderfully expressive language, full of safeguards against various common careless errors. Perhaps people benefiting from managed code will be more receptive to the Pascal idea that being very explicit about your intentions helps prevent mistakes.

Delphi and .Net
Since the February 2002 announcement that Borland would port Delphi to .Net, many of us have referred to the new product as Delphi.Net. Apparently Microsoft objected to this name (probably on trademark dilution grounds) and what we’ve been calling Delphi.Net will be called “Delphi for .Net.” I guess we’ll all just abbreviate that as DfN – certainly DfN2 isn’t as obviously funny as “Delphi for .Net 2.”
DfN will produce 100% managed code. That is, it will generate only CIL that you can run through the Microsoft PEVerify utility to prove that it is “memory type safe”. Type safe code plays by the rules, and doesn’t do tricks like read other object’s private fields. .Net code doesn’t have to be verifiably type safe, but unsafe code requires special permissions to run. For example, the Microsoft WinForms classes, which are how you build GUI’s in .Net, are unmanaged code that ultimately thunks down to the existing Win32 libraries like User32, ComCtrls, and RichEd. They come signed by Microsoft in a way that asserts that they’re just as safe as the libraries they call. These libraries may not be perfect, but you’ve been using them for years.
With Delphi for .Net, you will be able to write WinForms applications, just as you can do with the Microsoft Development Environment (aka Visual Studio .Net). Borland will also write a version of the VCL for .Net – the familiar Delphi control set implemented as unmanaged code that ultimately thunks down to the existing Win32 libraries like User32, ComCtrls, and RichEd. This library will be signed by Borland in just the same way that WinForms is signed by Microsoft. My guess would be that VCL for .Net won’t be 100% compatible with the existing native VCL, but since it is ultimately calling the exact same libraries that the VCL does now, it should be more compatible than the CLX, which has to implement VCL-like behavior using Qt.
Whether your desktop application uses WinForms controls or the new VCL for .Net controls, it will be able to use all the functionality of the Microsoft framework classes – the new, object-oriented API that covers everything from web services and object serialization to a nice set of collection classes and Perl-compatible regexes. Your decision to use WinForms or VCL for .Net for any given project will be based mostly on your plans for that project: WinForms projects should run on any platform that supports .Net (like IA64 platforms in a couple of years, and possibly OS/X or Linux) while VCL for .Net projects will require a Win32 host but can be more easily ported from (and to) Delphi or Kylix.
Delphi for .Net will ship sometime in 2003. D7, which will ship in 2002, will include a “Preview Edition” of Delphi for .Net, which will include (at least a preliminary version of) the VCL for .Net library and the DCCCIL command line compiler, which compiles Delphi source to .Net assemblies. (A Net assembly is a standard Microsoft PE [Portable Executable] file, which contains CIL and metadata instead of Intel object code. Every entry point in the PE file points to a stub which JIT compiles the code and then modifies the entry point so that future calls just go straight to the compiled code. Metadata is basically just a generalized and extended version of Delphi’s RTTI.) While obviously the Preview Edition will be a lot harder to use than the eventual full blown Delphi for .Net, you will be able to use it to build .Net applications in Delphi. In particular, you will be able to embed Delphi code in ASP documents, the way Anders did in his keynote.
New syntax
There will be language changes. Many of the changes are necessary to support .Net, but others seem to be coming ‘just’ because the compiler guys want to do some cleanup while they make the biggest changes since Delphi 1 (exceptions and a new object model) or Turbo Pascal 4 (the unit syntax for separate compilation.) These language changes will also appear in future versions of Delphi for Windows and Kylix to maximize portability between Delphi for .Net and the ‘Classic’ Delphi’s (the ones that generate native Intel code.) However, while Delphi for Windows code will be able to use Delphi for .Net syntax, it won’t have any access to the .Net runtime library (the framework classes) or to standard .Net object methods like ToString and HashCode.
In .Net, Delphi’s TObject will be a System.Object. (If Borland didn’t map TObject this way, then TComponent wouldn’t be a System.ComponentModel.Component, and Delphi components wouldn’t be playing in the language-neutral space.) Since System.Object does have methods like ToString and HashCode that TObject does not, Borland is adding the concept of helper objects like
THelper = class helper for TObject;
THelper lets you add methods to TObject that subsequently look as if they are declared in TObject. While I imagine that helped classes will have two separate virtual method tables, methods introduced as part of a helper class will be syntactically indistinguishable from normal classes. In particular, every method added to a class, whether TObject or one of its descendants, is available to any descendant of that class.
We’ll also get several C# language features which are used extensively in .Net. Attributes are basically a way to inject custom metadata into your assemblies. This metadata is available at runtime, and can control things like how an object is represented in XML. You can also define new attributes to add any custom metadata you want to your code. Syntactically, attributes are text in square brackets before the method or type they apply to. This is very like a GUID and, if I understood correctly, the existing GUID parser will be trashed and GUID’s will just be handled as a special case of attributes – an attribute in the right place, with the right sort of text, will be treated as a GUID.
Delegates are the .Net version of Delphi event handlers: an object/method pair which is called whenever the right sort of thing happens. The big difference is that where Delphi events always have zero or one handler, .Net events are always multicast. That is, each event can have multiple handlers, much like in Qt with its signals and slots. Delphi for .Net will support both the traditional VCL-style single-recipient syntax and the .Net multiple-recipient syntax. The traditional OnEvent := Handler syntax will still work, and the Include() and Exclude() set operators will be extended to allow you to add and subtract multicast handlers. The two systems will be completely orthogonal: Setting or clearing an event handler won’t affect the multi-cast list, and editing the multi-cast list won’t affect the traditional single-cast handler.
There are no variants in .Net, and boxing and unboxing are a big reason why. Where a language like Perl allows you store any scalar – a typed value much like a variant – in a hash or an array, .Net’s containers all hold objects. When you supply a value type, like a number, where an object is expected, the system automatically boxes the value into an object. The boxed value then has functional versions of all System.Object’s methods, like Equals, ToString, and HashCode. (Yes, this means you can use dates and numbers to index a hash.) When you need the original value back, you unbox it by casting the boxed object to the type it holds. (There is no such thing as an unsafe (blind) cast in .Net. All casts act like Delphi’s “as” operator – they are checked against RTTI to make sure that this cast is actually valid.) Delphi for .Net will support boxing and unboxing. It will also include something like Kylix’s portable variants library, so that legacy variant code can be ported easily.
The Variant datatype will be only one of the Delphi constructs that aren’t part of the CTS [Common Type System] requirements. Others include sets and unsigned integers. Some .Net languages (like C#) can understand unsigned types, but others (like Visual Basic) can’t. In all probability, Delphi will be the only .Net language that can understand Delphi’s variants and sets. You can expose non-CTS data types as part of a cross-language component, but you should provide CTS-compliant ways to access the non-compliant features. Delphi for .Net will be able to warn you when you are exposing non-CTS compliant data types.
.Net features hierarchical namespaces. Flat namespaces means that every namespace’s name potentially conflicts with every other namespace’s name: Two vendors can’t both ship a Collections namespace. With hierarchical namespaces, we have the System namespace as well any number of others, rooted in vendor trademarks. Thus, the System.Collections namespace doesn’t conflict with a (hypothetical) Microsoft.Collections namespace or a (hypothetical) Borland.Collections namespace.
Delphi for .Net will support hierarchical namespaces. We’ll be able to use dotted names in uses clauses - like uses System.Collections – and then use those dotted names as part of a fully qualified name in code like HashTable := System.Collections.Hashtable.Create. Since those dotted names can get pretty long, we’ll be able to define aliases in the uses clause – like uses System.Drawing.Text as GuiText – and then use the alias in a fully qualified name in code like FontCollection := GuiText.FontCollection.Create.
The CTS specifies case-insensitive Unicode identifiers, and Delphi for .Net will go along with this. Programmers in non-English speaking countries will be able to use Unicode identifiers in their programs. However, relying on a distinction I don’t quite understand, Unicode ideograms (like Chinese and Klingon) will not be allowed.
Since Delphi reserved words like “label” and “case” are not necessarily reserved words in other .Net languages, you’ll be able to use reserved words as part of qualified names. (The first word in the qualified name can’t be a Pascal reserved word. Tough luck for Procedure™ Corp customers.) Thus, if the FooCo.Whizzamatic class has a Label identifier, you’ll be able to write code that refers to FooCo.Whizzamatic.Label. There’ll be some sort of escape mechanism so that you can do things like override the Label method when you inherit from the FooCo.Whizzamatic class.
Changes to class syntax
There will be a number of changes to class syntax. We will get nested types, where a class like Foo can define a helper class like Bar, whose identifiers are only visible within Foo’s methods. For example,
Foo = class
Bar = class
procedure Method;

procedure Foo.Bar.Method;
// can only be called within a Foo method
Along the general theme of “more dots,” there will be a new syntax option for method resolution clauses. Where we now have to separate method declaration from method resolution and write declarations like
TThis = class (TInterfacedObject, IThis)
procedure IThis.Foo = ThisFoo;
procedure ThisFoo(N: integer);
we’ll now be able to write code like
TThis = class (TInterfacedObject, IThis)
procedure IThis.Foo(N: integer);

procedure TThis.IThis.Foo(N: integer);
We will be able to have class properties, not just class methods. We will be able to declare static class methods, which will not have a Self parameter that reveals the type of the class that the method was actually invoked on. Much like in Java and C#, we will be able to declare sealed classes that can’t be inherited from, and final methods that can’t be overridden.
Changes to record syntax
There will be two really wonderful changes to the record syntax, which will preserve the useful parts of the old-style object model and allow the “object” keyword to go away. First, records will be able to inherit from records. This means that new fields are added into a flat namespace, just as with object inheritance, and you end up with simple identifiers like This.Name instead of very dotty, nested identifiers like This.That.TheOther.Name. This technique used to be very useful to declare types that consisted of a fixed-size header and a variable amount of data – like a bitmap – but that sort of thing is frowned on in .Net. The .Net approach uses a header object that has something like an “array of byte” field for the variable length data.
Second, records will be able to have methods. Thus, when you find you have a lot of routines that take a record type as a parameter, you can just make them methods of the record instead. This gives you many of the syntactic advantages of objects without any of the dynamic memory overhead: local records are allocated on the stack, and there’s no cost to Create or garbage collect them; an array of records is a single data structure, not an array of pointers to objects.
The interaction between inheritance and methods is a bit complex – as I understand it, records will be able to inherit only from records that don’t contain methods. As soon as a record contains methods, it’s sealed and can’t be inherited from.
New semantics
.Net is a garbage collected environment. That means we can all forget the old Free What You Create rule. I imagine that Borland will build some sort of mechanism so if ported code does Free an object, the garbage collector won’t try to run the destructor again during finalization, but that’s just me – Borland didn’t say anything about it at BorCon.
Garbage collection also means that Delphi doesn’t need to use reference counting to Free strings, dynamic arrays, and interfaces. Those types will still be available, and – with one exception - will act the same, but they will no longer be reference counted. This means that assignment of every one of these types will be faster; it also means it will take less time to call and return from every routine that now has reference counted local variables.
If you don’t explicitly Free an object, its destructor only gets called when the garbage collector needs to reclaim the space. Thus, one big difference between interfaces in Delphi and Kylix and interfaces in Delphi for .Net is that on .Net an interface’s destructor doesn’t get called the instant the last reference goes away. That is, if you have been using interfaces for resource protection, current plans mean that your code will break. If you open a file in append mode and wrap the handle in an IStream interface, your file won’t close as soon as the stream is all written. If you store the current Cursor in an interfaced object before changing Screen.Cursor, the system Cursor won’t be reset when the procedure that set it returns; it’ll be reset at some random time later, perhaps after some other code had made its own changes.
If losing reference counting would break your code in this way, you probably ought to let Borland know. It’s at least theoretically possible to bring a limited amount of reference counting over to .Net, and Borland may do so if it keeps enough code from breaking.
Dead syntax
In addition to the changes I’ve just sketched, some existing syntax will not work on .Net.
.Net is all about managed, type safe code, where the system knows the layout of every structure it may garbage collect. Thus, the untyped memory functions – GetMem, FreeMem, and ReallocMem – will not be supported under .Net. (New and Dispose will still be supported.) Similarly, untyped var parameters and the @ and Addr() operators will be illegal in Delphi for Net.
On .Net, the actual size and layout of a record will depend on the current hardware platform. This has two immediate consequences for Delphi code. First, you won’t be able to use the file of type syntax on .Net. Using .Net’s SOAP serialization code to stream records and objects in a portable manner is the closest you will be able to get to this type of random-access record-oriented file. Second, SizeOf() will not be a compile-time constant on Delphi for .Net and, as I understand it, it’s unclear whether it will have to be a run-time function or whether it can be made into a JIT-time constant.
Obviously enough, inline x86 assembler (BASM) won’t be legal on .Net. Apparently, the current plans are that Delphi for .Net won’t include a BASM that understands CIL, either. I’m not sure if this is a cost-of-writing-a-CIL-assembler issue or not, and I’m not sure how much I really care about losing BASM – in recent years, about all I’ve used it for is things like the RDTSC instruction, or using IMUL to get the 64-bit product of multiplying two 32-bit numbers – but I suspect that some people will be very upset if BASM goes away entirely.
It may not be possible to implement virtual constructors on .Net. Obviously, this would break all sorts of sophisticated code, and so Borland would like to implement this, but apparently there are some technical barriers they may not be able to overcome. If necessary, code that currently uses virtual constructors can be rewritten to use RTTI to find the appropriate constructor.
Finally, some old syntax that’s been deprecated for a while – the absolute keyword, the real48 data type, the whole ExitProc chain, and the old-style object keyword - will no longer be supported at all. "

If I helped, please click 'Accept as Answer'. Thanks.

Best regards,
Reply With Quote
Old 06-22-2002, 09:29 AM
HTML HTML is offline
Senior Member
Join Date: Jan 2001
Posts: 2,977
Default RE: Does Delphi Support .Net Technology?!

Hello, :-)

Delphi7 isnt exactely Delphi.Net, but is .Net friendly have a look here,
Reply With Quote

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT. The time now is 03:30 AM.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2019, vBulletin Solutions, Inc.