Fog Creek Software
Discussion Board

Start from scratch

Joel, I enjoy reading your writings, but that does not mean I agree with all. I have a desktop application in Visual Basic which took 2 years to develop, and now for 2 years in the production with several releases. I had a though time to decide if I will go on with Visual Basic 6.0, or consider VB.NET or else? So I decided on Delphi!

The application is used for realtime stocks data feed display and technical analysis. The important factors are:

1. It should ve very fast
2. Should allow for at least 30-40 forms displayed without memory (GDI) problems.

I had other criteria on my mind such as, it will be best to have a standalone executable, with no dependencies whatever.

I considered VB.NET or C# seriously. But my clients have PC's ranging from 16 MB Win95 to 256 MB W2000. I don't know how much and how big will the .NET distribution will I send to clients, and when I load .NET on Win95 will it be Win95 still!?

You say that you can convert CityDesk to VB.NET in just 2 weeks, which I doubt seriously. I have 80,000 lines of Visual Basic code with lots of external C++ DLL's for speed, which makes converting to VB.NET as easy (or as hard) as converting to Delphi.

So you see, despite all you say on writing from scratch sometimes you don't have any other choice. Currently I feel that I already put too much stress on Visual Basic 6.0, and I am really frightened to go any further.

Why Delphi? I considered every language/platform I knew of, from C++ to Eiffel. I think Delphi gives everything I need from speed to standalone executable, from very low level to very high level sophistication. The only challenge is I can programme eyes shut in Visual Basic and I will need some time to get used to Delphi at similar full speed.

Thus I need advice from you people at this forum. My program is the main revenue generator for my company and is installed at more than 3500 clients. This makes the decision a very strategic one.

Aydin Sakar
Thursday, December 20, 2001

If it helps, I've never heard of anybody going to Delphi and then giving up on it for something else... whereas there are several well known examples of people giving up on VB (Hotdog springs to mind immediately).

Thursday, December 20, 2001

I don't know much about Delphi, but I certainly wouldn't bet a revenue-critical app on an unreleased framework! Oh wait, I did this. But our rollout isn't until next year, so I'm keeping my fingers crossed.

When you say you are putting "too much stress" on VB, what are you doing? How is delphi different?

Thursday, December 20, 2001

Here's a list of Delphi recommendations.

Just about every Delphi question has already been asked on the Borland forums. You can search the Delphi newsgroups at . Look for answers by TeamB members. They are the real experts.

If you can not find the answer go to the Delphi newsgroups at There are many helpfull people hanging around there.

Depending on the type of application you are developing there are probably a couple of add ons you like to get. Great as Delphi is, it contains several components out of the box which I would recommend against using.

For local and simple client server database get DBISAM ( ). Don't use BDE/Paradox which comes with Delphi. DBISAM compiles right into your exe, so no dll installation hell or middleware configuration. It's also almost impossible to corrupt and very fast.

For DB reports and a very powerfull end-users designer get ReportBuilder ( ). Don't use quickreport which comes with Delphi. It's crappy.

For data-aware components/grids with advanced features, like Excell type filters, use the QuantumGrid from . The standard Delphi data-aware components are good, but these are the ones that make your application stand out from the competition.

Installer: Inno Setup ( ) And another time: Don't use Installshield Express which comes with Delphi.

Internet components: Use Indy ( ) instead of the Netmasters ones. Both come with Delphi 6.

Jan Derk
Thursday, December 20, 2001

You obviously didn't spend much time looking at VB.NET if you thought that a port to dotnet was as hard/easy as a port to Delphi. You really don't need to throw your code away when you move to dotnet, a great deal of effort has been put in to interoperate between "legacy" code and new code.

It is all too easy to dismiss an option that requires a bit of study beforehand when the alternative is to throw away code and start again. However tempting the second option may seem, it is almost always wrong.

John C
Thursday, December 20, 2001

1. I need really fast DB access so I prefer to write my own.

2. What do you think about ICS socket library. They are async and Indy is blocking, I couldn't decide which to use.

3. I have to decide on Menu structure and components to use. I want very flexible, fast, centrally manageble menu, toolbars and context menus. I am looking at DevExpress ExpressBars but unfortunately they don't have a demo download.

John C:

I spent a great amount of time looking at VB.NET, but my first concern was about the distribution size. I cannot afford to distribute 18 or so MBytes of MS code and Dll's to my customer, just to discover that I have to redistribute at next Service Release!

Aydin Sakar
Thursday, December 20, 2001

What about Delphi + IBObjects + Interbase/Firebird ?

The only drawback is that Interbase has to be installed, besides the executable, but you can make an installer, wich installs both your app and interbase silently.

Szasz Attila
Thursday, December 20, 2001

Aydin Sakar ----------------------------------------
when I load .NET on Win95 will it be Win95 still!?

Microsoft ----------------------------------------
The redistributable package runs on Microsoft Windows® XP, Windows® 2000, Windows NT® 4.0, Windows® 98, and Windows® Millennium Edition (Windows Me). Microsoft Internet Explorer 5.01 or later is required

.Net doesn't support win95.  Unless you want to force your win95 customers to upgrade .Net is not an option.

Aydin Sakar ----------------------------------------
I have 80,000 lines of Visual Basic code with lots of external C++ DLL's for

Perhaps you can use ActiveX components to phase the conversion.  Both Delphi and Visual Basic support ActiveX.

1) Break your current code up until ActiveX components.  Make sure that it works in VB6 in component form.

2) Recreate the application in Delphi with all of the functionality still within the VB produced ActiveX.

3) Rewrite each individual component in Delphi, ensuring that no interfaces are broken.  Some automated unit tests would be useful here.

I appreciate that in the interrim you have the problem of maintinaining sourcecode in both languages, but the benefit is that your code is that you will always have code that is close to releasable.

Ged Byrne
Thursday, December 20, 2001

"1. I need really fast DB access so I prefer to write my own."

For full featured local databases DBISAM is as fast as it gets. But if you don't need SQL/Transactions/Multi-User/Etc then a more basic custom solution will generally beat that.

"2. What do you think about ICS socket library. They are async and Indy is blocking, I couldn't decide which to use."

I guess it depends on your personal preferences. I never had a problem with the Indy blocking model. It's dead simple to Internet stuff with it, got proper exception handling and has a nice anti-freeze component for programmers that don't want to go into threading. If I'm not mistaken Unix Sockets are also blocking, which is probably why Indy supports Kylix. You might want to keep that in mind if you ever consider porting to Linux. But I recommend you ask the real experts in the Delphi Winsock newsgroup. There are many people much more experienced on this area than I am.

"3. DevExpress ExpressBars"

I'm only a user of the DevExpress grids. So no personal experience with the Expressbars. I can only state that the DevExpress components are generally very high quality. Again you will get a much better answer in the Delphi newsgroups.

Jan Derk
Thursday, December 20, 2001

You might find delux interesting.  Its a VB to Delphi converter.

Ged Byrne
Friday, December 21, 2001

Hey, don't drop your application. My first advice is not to start over.

But if you are really commited to start again, you should do the following: stop any new development in the old codebase, but keep a small team of programmers doing cleanups, fixing bugs and doing general maintenance.

I think the ActiveX approach to do the migration should be very interesting, too.

Leonardo Herrera
Friday, December 21, 2001

*  Recent Topics

*  Fog Creek Home