Fog Creek Software
Discussion Board

VB6/ATL or .NET for shrink-wrap software?


Our company is about to start development on a new product.  This product will be geared towards application developers and system administrators within the windows environment.  We have come to a critical decision point, which is:

Should we use .Net or stick with the VB6/ATL paradigm we are familiar with? 

We see the overall benefit of using .Net, and we also know of the possible pitfalls of embracing any new technology, but given that Microsoft is pushing full steam ahead with .Net we feel it will be the development environment of choice for the Windows platform.  We also have good Java experience, so C# is a very comfortable programming language for us.  One of our major problems is the fact that the CLR is not widely deployed, and disseminating it may be an issue because of its size, and the fact that we are going to be selling this software on the Internet.  We are thinking since this product is geared towards developers and administrators this may not be an issue.  Any opinions on this strategy, other criteria we should consider, or thoughts in general?



Garett Chang
Monday, December 30, 2002

Well, consider the issue of installed base, too.

VB6/ATL has an installed base.  Most likely enough of one that you are ensured that, 10 years down the road, you and every other user of VB6/ATL will have some sort of upgrade path to work on whatever everybody else uses.

The problem with .NET is that if all the CLR and .NET stuff don't go anywhere, you run the real risk of having your product based on a splinter technology with no future and needing to go through a language change to get off of the splinter.

I'm not sure, tho.  I know people were excited about .NET last year, but I'm not sure what the feeling is this year.

Monday, December 30, 2002

You're unfortunately in a tough situation, because you're distributing over the Internet. If you're primarily building server-side software (which is what I do; probably 90% of what I wrote this year was VB.NET/ASP.NET code), software for internal use (and therefore on high-bandwidth internal networks), or software distributed on CD/DVD (where you can just put the framework on the disk), moving to .NET is a no-brainer.

But Internet downloads are messy, because a 20 MB runtime takes a while to download at 56K, and you can't assume people have it yet. As MS starts including the framework in anything and everything they ship (and they will), this will be less of a problem, but if you're planning on shipping in 2003, you can't count on this effect yet.

I don't know if any of the various installer manufacturers have built a good 'download/install the CLR from Microsoft if it's not already installed' routine yet, but if they have, or building such a thing isn't difficult for you, I'd go the .NET route. That's where Microsoft's tools are going to be for the next five years at least, and, well, I can't imagine doing anything serious in VB6 or VBScript anymore.

Dave Rothgery
Monday, December 30, 2002

Dave says..

"I'd go the .NET route. That's where Microsoft's tools are going to be for the next five years at least, and, well, I can't imagine doing anything serious in VB6 or VBScript anymore."

I agree, although I still think that a 'bit' of VB6 stuff will still get developed, basically by people in the same position as you are in now who decide to do VB6, I think that in a years time they'll wish thay had gone the .NET route.

Monday, December 30, 2002

Delphi always seems to get a plug in on this forum, so here goes:

I've chosen Delphi as a development tool when faced with a situation very similar to yours. 

My prior experience was exlusively with MS Access and VBA, and I was looking for a language to use to develop an app that would be distributed over the internet. 

Delphi has been pretty easy to pick up.  It would be even easier to pick up for programmers who have Java experience.

Delphi has advantage in deployment over VB in that components are compiled into the executables.  No messing with "dll hell".

In addition, Delphi for .NET will be coming out soon.  It's expected that there will be some sort of "VCL for .NET" included, which will make it possible to use native Delphi components (in the Visual Component Library) in .NET.  So in theory the port of a Delphi Win32 app to Delphi for .NET should be fairly straightforward, when and if you do decide to port your app to .NET.

Herbert Sitz
Monday, December 30, 2002

"Delphi has advantage in deployment over VB in that components are compiled into the executables."

That's an advantage? :-)

Tuesday, December 31, 2002

Hmm.  Well, yes.  ;)

Delphi can use ActiveX Components just like VB.  Or you can use VCL components that are compiled into the executable.  Or you can use VCL components and structure your program into an executable with .dll's (or Delphi "package" files).

One big advantage is that you can often simply distribute a single .exe file, no need to write an installer program to install the components.  Also no possibility of things getting messed up with different versions of components on the target computer.

So, yes, I'd say having the flexibility to compile components into the exe, when you want, can be a big advantage.

I'm not tryng to suggest that Delphi is Garrett's best choice for the problem he's facing.  But it is one that he at least ought to be aware of because there are some advantages it has over either of the options he's currently considering (VB6 or .NET).  Delphi would have disadvantages, too.  Two disadvantages might be simply that (1) Delphi is a proprietary language and the proprietor is not MS, and (2) Delphi isn't open source.  A third disadvantage is that developers would need to "ramp up" on Delphi development.

But I like to be aware of any feasible option when making a decision and I assume other people do, too.  (That's my peremptory defense against people who suggest there's too much Delphi-pushing on Joel's site.)

Herbert Sitz
Tuesday, December 31, 2002

I would add that Garett's target users being developers and administrators should sway his choice towards .NET.  Users of my app are generally computer illiterate and many have slow computers with OS's as old as Win95.  I'm not sure what I would have chosen if I could have been confident my users would all be computer-savvy and have up-to-date machines.

Herbert Sitz
Tuesday, December 31, 2002

I would certainly be reluctant to begin a new project in VB6. Someone mentioned getting stuck on a spar. Well I think VB6 is getting that way. There will be no new versions or upgrades to VB6. Windows will eventually move to a 64bit world, and VB6 will be very much left behind in a 32bit one.

The problem is that the .NET framework isn't going to be widely distributed until the next release of Windows dwsktop, which will be 2004 at the earliest, so in the meantime most users will have to download the 20MB runtime. In the broadband world, this isn't a big problem, but in the land of dial-up, that's a big investment to ask of your users. People will di it if they really want your application, but it better be worth it!

Bear in mind, if your customers are mainly corporatations, installing the framework over a corporate network is fairly trivial, so no problems there.

You really need to look at how long your development cycle is, and how long before you need to return a profit, and how long you intend your application to be around. If it's going to take a year to develop, and you plan it to be around for a long time, then slow downloads for a few months until WinWhatever gets established shouldn't be an issue. On the other hand, if you need to be turning a profit in three months, than it's probably worth the extra work for a .NET conversion in a year or so.

There is also the Delphi option. Delphi is mooted to be moving to .NET in the near future. However while Delphi apps are likely to be easier to migrate than VB6, I'm not convinced it's going to be as trivial a process as some suggest. It may be easy to get it working, but turning an app into a true .NET app (replacing old-style calls with new .NET framework classes) will probably still require a lot of work.

Happy new year,


James Shields
Tuesday, December 31, 2002

Regarding the Delphi port to Delphi for .NET, you can get some info and a tutorial on it here:,1410,29320,00.html

Goes over porting a Delphi Win32 app to .NET using VCL for .NET (fairly easy) and doing a port to WinForms on .NET (more involved).  These are real working examples using the Delphi for .NET preview command-line compiler  included with Delphi 7.

Herbert Sitz
Tuesday, December 31, 2002

"...This product will be geared towards application developers and system administrators within the windows environment."

While it is understandable why you don't want to talk about the product your company plans on developing not doing so makes it hard to provide you with any type of practical advise.

Sounds like whatever your company plans on building that it will be a very generic type of tool.  If this is the case, then I would stay away from using Java or a .NET programming language.  Sounds to me like you would be better off using VB, Delphi, or C++ to build your product since your target audience seems to be just about everybody who uses Windows.

Which Windows environment(s) do you plan on supporting?

Will the product only work for English speaking developers and admins or are you going to support different languages?

Can developers purchase the source code so that your product can be customized?

Blah, blah, blah....

One Programmer's opinion
Tuesday, December 31, 2002

Happy New Year!

Just returned from vacation, and was surprised to see all the great feedback.  Don’t you people ever take a break:)

Since we are thinking long term, going the .Net route seems to be a strategically good.  However, balancing the need to think about the future and returning a profit is crucial, as James articulated.  Herbert, you have a good point in that our primary users will be fairly computer literate (I say this cautiously, because I’ve worked with developers and sysadmins who were not), which will help us if we went with .Net.  Also, we plan on targeting, but not limiting ourselves to, corporate customers, English speaking initially and international in the future, which does affect our decision.

Being that this tool will be somewhat generic, as One programmer stated, I wonder if this really affects our decision.  By the way, we are planning on supporting only NT4, W2K, and XP.

Again, thank you all for the insightful comments.


Garett Chang
Thursday, January 9, 2003

Nobody I know uses anything but Win98 or some Linux flavor on thier home PCs. I use Win2000 at work (not by choice), but most of my fellow programers at work use win98. The advent of 64 bit machines is the only thing I can imagine that would lead me to upgrade or change my OS- and that would probably be to a Linux only machine -it'll probably be mature enough by then.

I seriously wonder if the .NET thing will be as big a hit as all the hoopla says.

Saturday, January 18, 2003

*  Recent Topics

*  Fog Creek Home