The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Delphi File Dependencies - If Any

I have heard a rumor that there are no file dependencies with a compiled Delphi EXE.  Can someone shed some more light on this for me?

Here are a couple of cases to consider:

1)  I use a 3rd party DLL that I call functions from.  Is this not needed to be distributed since it is somehow included in the compiled EXE?

2)  What about files that cannot be distributed such as the MS Outlook library?  How would that work?

Thanks.
Ignorant Dude
Wednesday, January 03, 2007
 
 
You can deploy Delphi apps in two ways: one way uses BPL files (which are Delphi-ized DLLs - basically DLLs with some added smarts).  I don't think may people do that,  because the other way is better: it is the single-exe deployment you have heard about.  It works like this:

Each Delphi source file gets compiled to a ".dcu" file (Delphi Compiled Unit). Then, the Delphi compiler links the DCUs together into a single exe.  Its quite smart about it, basically taking from the dcus only those methods which are actually used in the application.  You end up with one exe file which includes everything your app needs to run. 

That applies to all the components used by your app - both yours and 3rd party ones - as long as those components are written in Delphi.  As soon as you need to interact with non-Delphi code (COM or plain Win 32 Dlls written in C++ etc) your back to traditional "DLL Hell" - no better or worse than any other 32-bit Windows development tool.

Of course, all of the above applies to the Win 32 version of Delphi.  The .NET version, presumably, produces ordinary .NET assemblies.
John Rusk Send private email
Wednesday, January 03, 2007
 
 
Delphi itself doesn't require external libraries. The runtime, if you can call it that, is linked into the application.

If you use an external DLL file, you would generally still need to ship it. There are ways to link in DLLs if you really want to, though.

The key here is flexibility. If you want to have a smaller EXE, you can compile your program to separate out the runtime. If you prefer a larger, self-contained EXE, you can do that also. And it's up to you how much of the runtime you want to separate out - you can do it all, or just some pieces of it. It's quite slick, actually.
Tim Sullivan Send private email
Wednesday, January 03, 2007
 
 
>1)  I use a 3rd party DLL that I call functions from.  Is >this not needed to be distributed since it is somehow >included in the compiled EXE?

You would need to distribute that DLL along with your Delphi EXE.

>2)  What about files that cannot be distributed such as the >MS Outlook library?  How would that work?

You would call them as usual, via the Outlook COM interface.

There is nothing magic about Delphi. You just have the option of compiling the VCL library into the EXE. I think even Visual C++ had that option with MFC 10 years ago.

The big difference is the many 3rd party Delphi component vendors allow their components to be embedded in the same way as the VCL.
MBJ Send private email
Wednesday, January 03, 2007
 
 
>I use a 3rd party DLL that I call functions from

Is the dll written in Delphi?  If so, try to get it in .dcu form.
John Rusk Send private email
Thursday, January 04, 2007
 
 
Since, if you get it in dcu form, then you _can_ embed it in your exe.
John Rusk Send private email
Thursday, January 04, 2007
 
 
>I have heard a rumor that there are no file dependencies >with a compiled Delphi EXE.  Can someone shed some more >light on this for me?

In general an Delphi program don't need other files like a VB program.
Let's say that you make a classic "Hello World!" program. If you make this program with Delphi, you just need copy the exe file to another computer.
If you do it with VB, do you need a bunch of .dll and .ocx to the program work.

Perhaps, if your program do Database access, then do you need the libraries to necessary to make that access.

>Here are a couple of cases to consider:

>1)  I use a 3rd party DLL that I call functions from.  Is >this not needed to be distributed since it is somehow >included in the compiled EXE?

In this case, it's necessary distribute the dll. A dll will not be compiled into your program, cause it already is a program.

>2)  What about files that cannot be distributed such as
>the MS Outlook library?  How would that work?

Sorry, explain better.

>Thanks.

Best Greetings

PS.: I apologize my "version" of english.
Roberto Skylord Send private email
Friday, January 05, 2007
 
 
I seem to recall there being additional complexities if you were using Delphi's bundled database engine - if memory serves, deployment then became quite complicated, though it was a price worth paying at a time when Delphi was the best option for writing database front-ends.

(Since I haven't used this stuff for many years, I may of course be misremembering, or later versions may have made things simpler.)
Iago
Saturday, January 06, 2007
 
 
It was difficult no install the BDE on your own, bur Bokland supplied merge modules to handle it. Installation was somewhat fragile, as I remember it.
MBJ Send private email
Saturday, January 06, 2007
 
 
Iago,

Yes, the DBE was a pain, even with Borland's merge modules.  So there was a very strong market in 3rd party BDE alternatives, so for most applications you could find an alternative which would compile into your app (or at least be easy to deploy).
John Rusk Send private email
Saturday, January 06, 2007
 
 
"Let's say that you make a classic 'Hello World!' program. If you make this program with Delphi, you just need copy the exe file to another computer.

"If you do it with VB, do you need a bunch of .dll and .ocx to the program work."

Of course those bits of support code have been in the base install of every release of Windows since around 98SE.


Seriously, this constant trolling by the Delphi community isn't going to gain it enough converts to make it worth while.

Do you hear me Nick Hodges?  I'd like to see an editorial about this on your blog.
Codger
Sunday, January 07, 2007
 
 
"Of course those bits of support code have been in the base install of every release of Windows since around 98SE."

Yes, but you seem to have forgotten that with the old VB the slightly differing versions of those files gave rise to all sorts of niggling and difficult to diagnose problems collectively known as ".dll hell". 

More importantly, Delphi developers have never felt themselves limited to the crappy controls shipped as part of Windows.  Instead, they've always used VCL and third party controls and support code, all of which they've happily compiled into the .exe.  This was a big advantage over VB, since at a single stroke it bypassed all the ".dll hell" problems that the poor VB programmers had.
Herbert Sitz Send private email
Sunday, January 07, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz