Monthly Archives: November 2004

Why does Delphi 2005 IDE require the .NET framework?

Now that Delphi 2005 is out and people are beginning to use it I’ve seen a number of posts on the Borland public newsgroups regarding the fact that the IDE itself requires the .NET framework and I thought I’d try to clear up a few questions.

Why does the IDE require the .NET framework even for Win32?
First, lets back up to the C#Builder development days or roughly 22-23 months ago when we started working on a .NET IDE one of the most obvious requirements was the need for a CodeDOM (here is a article discussing the “CodeDOM“).  At that point, we did a lot of research into developing a CodeDOM which aided us later during the development of the Pascal CodeDOM for Delphi 8 (and now Delphi 2005).  The CodeDOM’s primary role is supporting the WinForms designer and is required because the source code for a WinForm contains all of the code necessary to instantiate every component on the form as well as set any properties of those components just like Java.  The IDE must be capable of writing and rewriting the form’s code as the developer modifies the form without messing code added by the developer.  This is very different from VCL where the code to instantiate components and set their initial property state is located within the VCL framework itself.  The VCL form designer creates a .DFM file that contains component declarations as well as property values but it’s the VCL streaming system that handles creating instances of these components and setting their property values.

Now, let’s move to the start of 2004 and the beginning of the Delphi 2005 development cycle when we were considering new features for the Delphi IDE.  One of the obvious features was Refactoring especially considering that we already had the powerful ability (via the CodeDOM) to  read and write Pascal source code.  We made the decision that instead of rewriting the CodeDOM to be Win32 based that we would simply leverage our .NET work and provide refactoring for both .NET and Win32 Delphi source code using the .NET based CodeDOM and thus the dependancy.  I believe this was the right decision and will continue to benefit the product as we move into the future given that we only have to maintain a CodeDOM on one platform.

If you have further questions please post comments to this entry.  Time to move onto the next question.

Why does the IDE require the J# runtime?
This is another good question and the answer is that the IDE itself does not require the J# runtime however the product includes features that do, namely StarTeam and Together.  Perhaps that sounds like a bit of a technicality but the reality is that the core IDE does not require nor use the J# runtime.  If you don’t use either of these features it is possible via the registry to disable the packages that load these features although I won’t dive into that in this blog entry.

Now, you might still be wondering why J#?  Well, the Together technology came from the Java world and more specifically from supporting JBuilder and thus was written in Java.  Once again, rather than rewriting the technology the decision in this case was made to leverage the J# runtime to support this feature.  I’m a bit less clear on the specifics regarding StarTeam although I know it supports an addin infrastructure which uses Java.

Hopefully, this helps explain the reasoning behind why the IDE requires the .NET framework.  Bare in mind that the Win32 applications developed using Delphi 2005 have no .NET requirements whatsoever and the fact that the IDE requires the .NET framework has no impact on whether or not your users must have it installed.

[BEGIN UPDATE Nov 27, 2004] One thing I wanted to mention is that while the default installation of the IDE requires the .NET framework it does not mean that it’s impossible to configure the IDE to function without it.  One such example has been documented here.
[END UPDATE]

Feedback

  re: Why does Delphi 2005 IDE require the .NET framework? 11/22/2004 12:48 PM Jesper Hogstrom

It may be worth noting that the Together Design Surface has two purposes in Delphi2005. One is Code Visualization, i.e. the ability to visualize source code into a UML diagram.

The other is to design models – and generate code – for use with Enterprise Core Objects, ECO. The latter is an Architect edition feature.

–Jesper

  re: Why does Delphi 2005 IDE require the .NET framework? 11/22/2004 12:54 PM Allen Bauer

I don’t want to be too to be pedantic, but the CodeDOM references are slightly off the mark. This in no way diminishes the reasons behind the descisions to continue to use the .NET work behind the code-parsers. In fact, I’d say the reasons go much deeper than strictly to the CodeDOM. To be accurate, there is an internal parser that can generate symbol tables and AST (Abstract Syntax Trees) using its own internal structures. From these structures, you can then obtain an MS spec CodeDOM. These same ASTs are also used to generate an SCI model (ie. a Together spec Source Code Interface). By leveraging this technology, we were also able to gain huge amounts of advancements in functionality with only incremental effort.

  re: Why does Delphi 2005 IDE require the .NET framework? 11/22/2004 1:05 PM Steve Trefethen

“I don’t want to be too pedantic, but…” Allen, are you sure about that? 🙂

  re: Why does Delphi 2005 IDE require the .NET framework? 11/22/2004 1:16 PM Allen Bauer

Hehe… OK fine… I was being pedantic ;-)…

  re: Why does Delphi 2005 IDE require the .NET framework? 11/22/2004 1:53 PM Liz

It would be prudent of Borland to put this somewhere on the requirements so as to aid in the soothing of potential users.

  re: Why does Delphi 2005 IDE require the .NET framework? 11/22/2004 2:15 PM Kyle Miller

I haven’t read the messages, but I sure hope people aren’t complaining that the IDE requires .NET. It’s a very small price to pay for the number of features the new IDE brings even for Win32 developers.

  re: Why does Delphi 2005 IDE require the .NET framework? 11/22/2004 4:38 PM Steve Trefethen

Hi Liz,
Technically, the .NET framework isn’t a system
requirement since it doesn’t have to be installed prior to installing Delphi 2005. If I had to guess, that would be the reason it’s not mentioned on the system requirements here: http://www.borland.com/delphi/pdf/del2005_sysreqs.pdf

-Steve

  re: Why does Delphi 2005 IDE require the .NET framework? 11/22/2004 6:52 PM Lloyd Kinsella

Is it possible for 3rd party developers to access the CodeDOM Delphi 2005 uses and if so how?

  re: Why does Delphi 2005 IDE require the .NET framework? 11/23/2004 2:20 AM Daniel Wischnewski

Hi Lloyd,

Corbin Dunn has made a blog entry on how to access the CodeDOM: http://blogs.borland.com/corbindunn/archive/2004/09/30/1493.aspx

Daniel

  re: Why does Delphi 2005 IDE require the .NET framework? 11/25/2004 2:12 PM Burak KALAYCI

So Delphi 2005 is also .NET infested. Whatever the reasons, I don’t like it. You say it’s not ‘technically’ a syste requirement, is it possible to run the IDE for Win32 without .NET then? (Is it the runtime or the whole framework? Does the command-line compiler work without .NET?) And what features are dependent on .NET? I’d be willing to turn-off some features, if possible, instead of getting the .NET bloat – if I ever move to Delphi 2005, that is.

Best regards,
Burak

  re: Why does Delphi 2005 IDE require the .NET framework? 11/25/2004 11:44 PM Steve Trefethen

Hi Burak,
First, if you’re a real Windows user you’d either better get used to the .NET framework or start looking for another OS, it’s that easy. Second, check out this post on the TeamB blog regarding how to run D2005 without the .NET framework installed.

http://blogs.teamb.com/DeepakShenoy/archive/2004/11/25/1945.aspx

  re: Why does Delphi 2005 IDE require the .NET framework? 11/26/2004 6:03 AM Burak KALAYCI

Thanks for the link Steve. As I see it, .NET is a ‘scripting language’ (term used loosely)as opposed to a ‘real language’ where you program for a real machine/CPU rather than a VM. There’s nothing wrong with ‘scripting’ but it just won’t satisfy my programming ambition. Maybe the time has come for a new OS 🙂 Sorry if my comment was on the harsh side, I was quite disappointed with the news.

Best regards,
Burak

  re: Why does Delphi 2005 IDE require the .NET framework? 11/26/2004 4:11 PM Steve Trefethen

Hi Burak,
Hmm, I’m not sure how you equate .NET with a “scripting language” but to each their own. Sounds like perhaps you should dig a bit deeper into what .NET really is and more closely examine all of the different technologies that it encompasses. If not, good luck with that new OS!

  re: Why does Delphi 2005 IDE require the .NET framework? 11/27/2004 4:57 PM Cengiz Can

Hi people,

I certainly agree with Burak on this issue. As a Delphi lover since version 3, I personally think that .net for Windows desktop applications is (in a crude expression) totally garbage.

Considering the performance and solidness of the applications, while comparing good old win32 and .net, I can surely say that .net is slow, choppy, and resource hogging just because of the dependencies.

We can say nothing about the choice that Borland made about this tech. But I think there must be an alternative way for the conventional programmers. Also, Since Delphi 7, everything is going down, hence the bugs and not-so-fixing update packages for 8th version.

While concluding my entry, I would like to notify you (considering you’re not aware of this) that, IntraWeb 7 which comes with Delphi 2005, does not contain an interface that can be integrated into Apache Web Servers. (Libraries are still there but there’s no wizard, no generation). I think this is a signal of what’s going to happen in the next few years.(Pushing out the Open-source solutions away, and better supporting of other commercial platforms.)

  re: Why does Delphi 2005 IDE require the .NET framework? 11/28/2004 10:17 AM Luigi Sandon

“what .NET really is”: judging from Delphi 2005 is just a way to build a sluggish, memory hungry app, with a pathetically slow and strange behaving GUI. Hope what you get in quantity (.NET has a huge “default” library) is lost in quality. Because speed and memory has paramount importance in out up (written in C/C++ and Delphi, on Linux and Windows) we don’t mind to have those ASP.NET stuff if we lose what is really important to us. Better to change OS fully, then.

  re: Why does Delphi 2005 IDE require the .NET framework? 11/30/2004 5:24 PM Charles McCrimmon

Only thing i hated about the .net framework being incorperated into Delphi was the loss of that amazing IDE that made me choose borland over Microsoft years ago. I utterly HATE the new styles of IDE i stuck with Delphi 7 and by the looks of the trial version of 2005 ill still be sticking with delphi 7, if i want to use what is basically MS VS then ill use that.. utterly shocking

  re: Why does Delphi 2005 IDE require the .NET framework? 11/30/2004 5:34 PM Steve Trefethen

Hi Charles,
I think you might be throwing the baby out with the bath water. Delphi 2005 supports both the D7 style of form designer as well as the single window IDE. Both designs have their merits and detractors and with D2005 you don’t have to choose unlike MSVS.

  re: Why does Delphi 2005 IDE require the .NET framework? 12/2/2004 8:52 AM Charles McCrimmon

I admit to overreacting a big on it, id get used to the new IDE in time and probably will but i still feel that the original style was much better, my main gripe is the web editor style form designer. it just doesnt feel as solid to me and i miss the tabbed components list over the floating tool palette, i know there mini gripes but to my the ide is everything if you dont feel comfortable with it your not going to use the development environment to its full potental. i like the inclusion of C# into the package for instance, im sure with a few months of usage of the new IDE i wouldnt have anything to complain about. basically i just miss the Delphi 7 style and im kinda not wanting to move onwards

  re: Why does Delphi 2005 IDE require the .NET framework? 12/6/2004 5:26 AM Elling Bjåstad

“First, if you’re a real Windows user you’d either better get used to the .NET framework or start looking for another OS, it’s that easy.”

Why the sarcasm? There are still very few .NET applications out there, and Win32 support will probably have to be part of any new Windows release for the next 10 years, at least.

An example: When do you expect for instance Adobe Photoshop or Discreet 3D Studio Max to run on .NET? Personally I expect never, or at least very far into the future.

That’s why I think Borland is moving a bit too fast when it comes to adding support for .NET. I think there is more time to be had than Borland currently seems to think there is.

I viewed Delphi 8 as a kind of prematurely released product, and from my initial glimpse of Delphi 2005 I’m disappointed to say that I have the same initial feeling about this product.

I think Borland ought to be a little more relaxed with it’s push for .NET compilance, and I think they ought to pay a LITTLE more respect to their existing Win32 user base… Just my two cents.

  re: Why does Delphi 2005 IDE require the .NET framework? 12/7/2004 12:22 AM Tom Reiertsen

I think Borland is doing every .Net sceptic a favor by forcing them to install the .Net Framework/SDK. .Net is a given. Microsoft has decided ages ago that this is the future of Windows development so the faster you get comfortable with it the better.

  re: Why does Delphi 2005 IDE require the .NET framework? 12/7/2004 5:18 AM Elling Bjåstad

.NET is kind of given. But it’s not given that there’s any rush to migrate over to it.

After all .NET is currently for instance VERY slow on GDI operations and screen rendering, and it’s generally a resource hog in all kinds of ways, as far as I’m concerned.

Also, it MAY be a mistake to be betting on WinForms right now, since Windows Longhorn will be introducing the Avalon API which will replace WinForms when it comes to development of Longhorn-only applications.

So I don’t think it’s necessarily stupid to place your bet on Win32 based applications until Longhorn arrives, and then to plan a transition to Avalon/WinFs/Indigo at that point.

I’ve not got the whole picture, I must admit, but as far as I can see .NET/WinForms can eventually prove to become more like a paranthesis between Windows2000/XP development and Windows Longhorn development.

Sure, a lot of the .NET technology will be present in Windows Longhorn, but still I think that for many types of applications it might be smart to hold your horses a little bit when it comes to starting a migration to .NET.

  re: Why does Delphi 2005 IDE require the .NET framework? 12/7/2004 12:11 PM Steve Trefethen

Hi Elling,
There is quite a bit more to .NET than just Windows client applications. Take ASP.NET for example, it’s really cool technology that solves many of the difficult issues related to bringing true RAD development to Web Applications. WinForms certainly has an adoption issue and perhaps an uncertain future given MS’s Avalon plans but from reading MS’s channel 9 website they are still working hard on WinForms and it doesn’t sound like technology that’s just going to disappear.

I really think in terms of Windows client application development it’s necessary to take a long term view of .NET because sooner or later, just like Win32 development, the advantages will be clear and compelling. Although for web application development I think .NET is already there and ASP.NET really has a lot to offer and ASP.NET 2.0 looks even better.

Given that .NET isn’t some shot in the dark by Microsoft and that it’s more of a tidal shift Borland has to respond and provide support for this new technology which I think is appropriate. I would have liked to have seen us include more new things for core Win32 development in D2005 but I think our priorities were right. There were lots of VCL bug fixes and the new IDE includes a lot of new productivity enhancements which are useful regardless of your use of .NET.

  re: Why does Delphi 2005 IDE require the .NET framework? 12/30/2004 7:33 AM Elling Bjåstad

I agree. Borland probably had no choice but to add .NET support to the Delphi product.

But I think maybe you could have waited with introducing the unified IDE. Maybe you could have released the first .NET versions of Delphi as Delphi for .NET 1.0 and Delphi for .NET 2.0? And then you could have kept the Win32 version as a separate product for one or two more relase cycles?

I think you MIGHT have benefited from doing that.

First, you would have created less confusion for the existing Win32 developers, and second you would have bought yourself some time in making the unified IDE more stable and Win32 friendly.

Of course… no use in looking back. But still, this is what I think you should have done… 🙂

  re: Why does Delphi 2005 IDE require the .NET framework? 1/20/2005 9:29 AM Rafael

My office has buyed the Delphi 8 .net recently and I think that Borland has a great “disturbe at Force” and, since the Dark Side is faster, was a good mistake on his market strategy.

I´m very, very sad with Borland becoming the “Darth Vader” of the software history!! Can anyone remember a video distributed by borland with a companion CD talking about open systems?? Remeber who was darth vader…

That´s all folks… i´m going to java…

  Wake up Borland 1/20/2006 8:31 AM matrix

Microsoft is not a technical leader it is a monster that re-creates the wheel. And denies inovation to sell in its next upgrade. Microsoft creates technology to LOCK out the competition WHEN will BORLAND realise this. DON’T follow .NET – instead refine the VCL – give people more power then what they have in all areas of VCL and IDE tools developement – Borland will never beat MS VC/VB/.NET at there game. Follow .NET is like shooting your foot.

  re: Why does Delphi 2005 IDE require the .NET framework? 1/20/2006 12:47 PM Steve Trefethen

Hi “matrix”,
All I can think to say is that I’ll respectfully disagree.

-Steve

  re: Why does Delphi 2005 IDE require the .NET framework? 3/2/2006 9:09 AM Sanders

I do agree with Matrix, this .NET thing is going nowhere.

If .NET is being used is not because of strict technical merit but because the corporate drones will buy anything MS.

The File Download Dialog and Delphi 2005 Welcome Page

Now that Delphi 2005 is shipping one thing that customers who are up-to-date with their Windows Update are surely going to run into when they launch the IDE is a File Download dialog prompting “Do you want to open or save this file?“ where the file in question is default.htm which is the Welcome page.  The reason this occurs boils down to the inopportune timing of a Microsoft Windows update release and our shipping Delphi 2005.  A similar dialog is displayed when the Help Insight window appears in the code editor and code completion listbox.  Allen Bauer has written a few blog entries (here and here) discussing all the gory technical details for those readers so inclined.

I decided to mention the issue here after reading Lino Tadros’ article A First Look at Delphi 2005.  Specifically, he talks about the above problem under “Delphi 2005: The Not So Good Stuff” section of the article but fails to mention that the workaround is to simply uncheck the “Always ask before opening this type of file“ checkbox on the dialog.  I think it’s a little unfortunate he decided to so prominently highlight this particular issue with two separate screenshots (both related to the same problem) and no screenshots of what he thought was cool.

Nonetheless, his point is made and I think illustrates the importance of a good first impression no matter how benign the issue and to that end we have a fix for the problem which I believe should be available within a reasonable timeframe.  This certainly isn’t the first time we’ve been hit by Mcrosoft patching something as we’re signing off and I’m sure it won’t be the last.

UPDATE:  While I mentioned two other links above I forgot the link to Allen’s blog to the entry that started this whole thing off:  Hello?  Microsoft Support?

Using the MSAA IAccessible interface within a Delphi Application

I’ve been investigating Microsoft‘s IAccessible
interface recently and thought I would begin a series of posts related to using
IAccessible in a Delphi
application from an MSAA
server perspective.  From the MSDN:

”The IAccessible interface is the heart of Microsoft Active Accessibility.
Applications implement this Component Object Model (COM) interface to represent
their custom user interface elements, which can include their client area as
accessible objects, if necessary.”

In order to start using IAccessible the first step is to import the
oleacc.dll type library which provides us with the necessary interface
declarations.  Having dug into this interface a bit I can save you a little time
and simply give you the TLIBIMP command line necessary to properly import this
type library.

tlibimp -Hs- -Hr- -Ftoleacc -Ps- -O- %systemroot%\SYSTEM32\OLEACC.DLL

If you’d like to import this type library from within the IDE make sure
to set Delphi’s type library importer so that it does not map the interface
declarations as safecall since some of the interfaces require a specific
HRESULT.  To do that select Tools|Options and change the Type Library option for
“Safecall function mapping” to “Do not map”.

The second step is to check the declaration of NotifyWinEvent API located in
Windows.pas to make sure it’s correct.  I found that it wasn’t declared as
stdcall which resulted in an AV whenever I called it.  If you ever find yourself
getting an AV when you call a Windows API function double check the declared
calling convention of the function import before going any further.

Here is the corrected declaration:

procedure NotifyWinEvent(event:
DWORD; hwnd: HWND; idObject, idChild: Longint); stdcall;

Ok, now that we have those two steps out of the way we’ve opened the door to
enabling our Delphi applications through MSAA.  Since this is a fairly large
topic I’m going try and tackle it in small pieces so stay tuned for the next
step.  In a future post I’ll begin to discuss actually putting this interface to
use.

[UPDATED: Dec 2, 2004 2:14pm PST] Chris Hesik of the Delphi
development team has written this
article
 where he discusses, among other things, one method for debugging
calling convention declaration errors.

IIS or ADSI do not appear to be properly installed

The title of this post is an error message that can occur if you are using Delphi 8.0 and trying to
create an ASP.NET
application using IIS as the target server.  I wrote this error message and for
that I apologize, as it’s a terrible message.  The error typically occurs when
the IDE is unable to utilize ASDI (an IIS API) to create a virtual directory for
the new application.

In Delphi 2005 I’ve tried to improve this message which now reads as
follows:

“Creation of a virtual directory “yourvirtdir” on the local IIS Web
server failed. The Web server may not be installed, not running or
misconfigured. Without the virtual directory you will be unable to run this
application however, you can manually create the virtual directory using the IIS
administration tools at a later time. Would you like to create the application
anyway?”

So, if you are using Delphi 8.0 and you encounter this error please
substitute the above text in it’s place.

Delphi Desktop States and the HTML/ASP.NET Designer

This issue has come up on the public Delphi newsgroups and I replied briefly
with some additional information and thought that perhaps a better explaination
of the issue might be useful/interesting at least to some people.

In C#Builder, Delphi 8.0 and now Delphi 2005 the readme states that the
HTML/ASP.NET designer do not support switching of modes while the designer is
visible.  Now you might be wondering why?  What’s the problem?  Well here is the
answer (in what is likely more detail than perhaps anyone wants):

The Galileo IDE (what we call it internally) which is the host for C#Builder,
Delphi 8 and now Delphi 2005 supports two modes for the code editor window,
docked and undocked.  This, more or less, means either a single window IDE or a
floating version (like all previous releases of Delphi).  In order to switch
modes a lot of “stuff” has to happen behind the scenes to
ensure that the switch works properly.

The main reason the HTML/ASP.NET designer does not support switching modes is
that the MSHTML
control (which we use as the design surface) has to be destroyed and recreated. 
That sounds easy enough but the problem is that you could be in the middle of a
document that has not yet been save which is where the complications start.  In
order to handle the destroy/recreate of the browser window the content has to be
streamed off and then restored after the designer is recreated.  This isn’t
necessarily a problem either, although you’d lose context information like
selection and caret position in the process, but it has to be performed at the
right time in order to work correctly.  Currently, the IDE is implemented so
that designers don’t have to have intimate details of what the rest of the IDE
is doing.  They get notifications when various events occur and can respond
accordingly however the dock/undock event is not one of the events that is
currently propogated to the designers making this a more difficult problem to
fix.  In the end, it’s simply come down to us focusing more on delivering
improvements to the designer itself since we felt that this issue probably won’t
effect a large number of customers.  Having said that I will say that fixing
this problem is on our radar and hopefully something we can get to soon.

Problems with Imported Type Library Declarations in Delphi

Since I’ve been working on the HTML/ASP.NET designer one of the things I’ve
noticed over the years is that our type library import tool improperly imports
certain declarations particularly when it comes to const (or [in]) parameters. 
I’ve run into method declarations where at least one parameter is declared as
“var” when in fact it should have been declared as “const”.  At best, this
results in no error but more frequently results in an application AV.  I’ve
talked to our type library gurus but unfortuantely this didn’t get addressed in
Delphi 2005 thus our
importer still suffers this problem.  Don’t worry I’ll keep at it.  🙂

Anyway, if you have imported a type library and you are pulling your hair
trying to call a method on some object try double checking that the method in
question is actually declared correctly.

For example, IWebBrowser2.Navigate is declared as follows once imported using
tlibimp.exe:

procedure Navigate(const URL: WideString; var
Flags: OleVariant; var TargetFrameName: OleVariant;
var PostData: OleVariant; var Headers: OleVariant); safecall;

Notice that the last four parameters are declared as “var” when in fact they
should have been declared as “const”.  If you try using this method you could
run into problems as a result of this misdeclaration.  The actual declaration
should be:

procedure Navigate(const URL: WideString; const
Flags: OleVariant; const TargetFrameName: OleVariant;
const PostData: OleVariant; const Headers: OleVariant); safecall;

If you take a look at the declaration here
on MSDN you’ll notice that all of the parameters are specificed as [in] in the
Parameters section so it doesn’t make a lot of sense for them to be declared as
“var“ in Pascal.  So, if you can’t figure out why you’re unable to call an
interface method from Delphi from a type library that you’ve imported double
check that the method is in fact declared correctly.

On a bit of a side note, I generated the MSHTML.pas
file that we use in the IDE with the following tlibimp.exe command
line:

tlibimp -Hs- -Hr- -Fe- \WINNT\SYSTEM32\mshtml.tlb

If you are running into problems specifically with MSHTML.pas please leave a
comment and if there is sufficient interest I’ll look to post our version of
MSHTML.pas to CodeCentral.