Fog Creek Software
Discussion Board

Shrink-wrap developers: what programming language?


I'm a shrink wrap programmer.  I develop, market, and sell software for speech therapy, primarily for older adults.  Think of it as geriatric educational software.

ANYWAY... our 16 programs were writtin in vb 3 and it's time for a rewrite. 

I'm considering:
* VB 6  : I already know it, it's a known, stable quantity.
*Delphi : a graceful language with no runtime required, but there's a learning curve, and it's a *little* harder than VB.
*  : unproven, large (20MB .net framework req'd), only supports win 98 and above and requires I.E. 5).

OUR PROGRAMS are fairly simple.  We don't need a fast compliled language and we don't do much fancy stuff.  We can (I think) make good use of inheritance and other OO capabilities in Delphi and
Our programs are about 20,000 lines a piece, but there is a lot of reused code (even more if we use OO, I think).



Clay Nichols
Monday, June 02, 2003

What's your timeframe?
If you need it done fairly quickly, go with what you know: VB6.

If you have the time, go with C#.

1) You're building a marketable skill.

2) C# seems to be successfully riding the C/C++ wave, earning buy-in from the "C snobs" (esp. those that don't know either C or C++). VB always has been, and always will be, perceived as a "toy language" - one step above "written in Excel macros"
For the record, I'm a VB programmer, and I know how powerful the language can be. But in general "the masses" think anyone can pick up a book and write VB applications...

3) In the "VB.Net or C#" question - it was either McConell or Cooper that suggested that MS should've called VB.Net "Visual Fred" because calling it VB.Net gives the incorrect impression that people who know VB have some kind of automatic leg-up with the language. (Sadly, this was in full effect at Camel - "We're using VB.Net because our people know VB")
The learning curve with .Net is the object model - the ".Net way of thinking." Getting past that is the same in either VB or C#. Many folks have said they preferred switching from VB to C# because the syntax is so different it helps keep the mind on track of "this is a different language" - that's the route I went and I agree completely.

4) Delphi. C# *is* Delphi 7.

5) Distribution of the CLR. Agreed that statically-linked Delphi is still the hands-down winner here. Sadly, Delphi is dead. So if you're not going to go with a single-file .exe, then what's the next least offensive solution? The CLR. I don't recall reading *any* installation problems with the CLR - as far as I can tell it's more stable than IE. Other than the CLR, your app runs as a single .exe and perhaps some dll's that don't even have to be registered.
If you're writing software to be downloaded - gotta link to the CLR, so that doesn't help. But since you mention shrink-wrapped software, I'll assume you have a packaged version. That's on CD, right? Are you really using all 640MB? ;-)

My $.02, anyway.


Monday, June 02, 2003

Why are you rewriting, again? 

"Because it's old" doesn't strike me as a reason in and of itself ...

"Because it's ugly" can be a plausible excuse ... but have you considered whether it's worth it to do a ground-up rewrite from a financial standpoint (will you get more customers if the UI is pretty?  enough new customers to justify the time and money to rewrite?)

I think you've already ruled out VB.Net for yourself, which is probably a good decision.  Having not done any Delphi programming, I can't give a recommendation between it and VB6.

Don't look at the VB6 runtime as a liability ... it's only a meg redistributable.  And certainly rewriting in VB6 would be an easier rewrite.

Monday, June 02, 2003

I think Philo and Alyosha both answered your question.

1) do you really need a rewrite, what do you gain?

2) if yes, then I think .NET (any flavour) is the way to go moving forward.

Monday, June 02, 2003

"Delphi is dead"

I've been hearing that since 1995. And never was this statement supported by arguments other than Microsoft is much bigger than Borland.

The irony is that all those developers choosing the safe option (MS VB) are the ones in the dead end street. They are now forced to rewrite in VB.NET or C# and having to put up with the large and easily decompilable framework. Does all .NET software now qualify as open source?

I guess when you are a monopoly you can easily tell your developers what to do.

Delphi 8 is coming and will support .NET, win32 and Linux. Delphi is like being in a horse race and you don't care which horse is winning because you're betting on all of them.

In an old topic the issue was raised that so many small application developers are using Delphi. That's because it is the most competitive environment around. Large enterprises may get away using less efficient tools, but those <10 person companies won't.

Jan Derk
Monday, June 02, 2003

I've worked at 2 shrink wrap houses, before becoming a consultant. We used Delphi for both shrinkwrap applications. In my experience, you are free to select the language freely when doing shrinkwrap stuff. People doesnt care what you write your stuff in, as long as it does something useful.

Politics around choice of language is just a problem when you are doing consulting.

Monday, June 02, 2003

The only criteria which separate doing shrink wrap and  tailored development involve packaging and installation.

If its shrink wrap you need to be sure that what you deliver is installable and supportable.  .NET involves packaging the framework as well.  If your customers are currently running VB3 built applications its unlikely they have the framework now, it may well be that they are running very old operating systems Win95 would not be unusual.

In such cases being on the edge of the wave isn't commercially secure regardless of how much of a rush it gives those producing it.

From the kind of application you do it may well be that existing users are price, or at least budget sensitive and would not thankyou and may even ignore upgrades which force them into major hardware and software renewals.

So the answer I'd ask before making the decision is 'what are my users capable of?'

Simon Lucy
Monday, June 02, 2003

Hi Clay.

Clay Nichols wrote, "I develop, market, and sell software for speech therapy, primarily for older adults....  ...OUR PROGRAMS are fairly simple."

I am confused. Do you work with other programmers or always by yourself?


Why do you care which programming languages other people are using?  Delphi and C++ are very popular choices when doing shrink wrap development simply because both are very flexible and powerful.

Clay Nichols wrote, "ANYWAY... our 16 programs were writtin in vb 3 and it's time for a rewrite...."

First question I have: Why do you believe it is time to re-write these 16 applications?

IMO, you really need to provide a very detailed explaination of the issues involved with your decision to do a re-write. My guess is that among others things, you want to add a lot of new functionality to these existing programs.

Other questions I have: What Microsoft Operating System environments (Windows 3.1, 95, 98, ME, 2000, XP) do your 16 programs currently run under?  What type of special hardware (microphone, scanner, printer, etc.) is needed to use your 16 programs.

Clay Nichols wrote, "We can (I think) make good use of inheritance and other OO capabilities in Delphi and"

Why are OO capabilities important to you for this re-write? Is the current procedural based source code hard to maintain?

Clay Nichols wrote, "* VB 6  : I already know it, it's a known, stable quantity"

Are you sure VB 6 is capable of doing the job all by itself? You may run into situation(s) where you are going to need to drop down to C/C++. There is a good chance that you simply don't know at this point in time what headaches or showstoppers await you and/or your team. If you or someone else on your team already knows C or C++ then VB 6 definately becomes a more attractive choice.

One Programmer's Opinion
Monday, June 02, 2003

Look at Smalltalk.  The download for the Windows version of BottomFeeder - an RSS Reader - is just over 5mB, and application updates are downloadable as well.  Have a look at - the languages you mention are not your only choice.

James Robertson
Monday, June 02, 2003

Depending on how much you can or wish to recycle (reuse) VB 6 is a good bet.

Delphi may well be a decent longer term option depending on how easily it can move projects from win32 to dotnet and linux. This may be the best option if you want to cover potential future possibilities but I wouldn't base a development choice on such possibilities (win32's going to be around for a while yet).

If you want to hit the macintosh market realbasic may be an option (never used their windows runtime but I've heard ok reports about it).

The bit I'd watch out for is not the development language itself but the components and other system calls your program depends on. I've recently seen a whole set of Cdroms that are totally incompatible with Windows XP due to changes made to windows sound drivers over the last few years. Regardless of whatever program their were written in (Delphi from my long distant memory) nothing short of a total rewrite is going to get them working under Windows XP.

Ben Thompson
Monday, June 02, 2003

It always amazes me to see people come on this board and post messages that read, "What language should I use or what language are you using for your products?", as if to imply that another language will somehow bring their product into a utopia.  Wake up people! C#, VB, VB.NET, C/C++, Delphi... who cares.  I really mean that. Who cares?  One person - you.  You are the only one that knows your product, your budget, your abilities.  Do you expect everyone else to guess?

A better question to ask is, "After analyzing my needs, I have planned to rewrite my software using C#.  Do you think that this is a wise business move because my customers will have to upgrade their hardware/software?"

Analyzing requirement is up to you, because you are the sole proprietor of those requirements.  Coming on this board and asking people what lanauge you should use is like asking if you should use a "case" statement instead of an "if" statement.  Only you can answer that.

You think I'm joking.  I'm not.

Monday, June 02, 2003

Use Lisp.

...sorry, couldn't resist. First time I've ever had the chance to say that :D

Monday, June 02, 2003

---"'ve recently seen a whole set of Cdroms that are totally incompatible with Windows XP due to changes made to windows sound drivers over the last few years."-----

I wasn't aware that XP made any difference to sound drivers. It bought in the Windows Driver Module WDM with 98 and developers were told to develop for that as it would be compatible with all future Windows OS's.

Many chose not to use it because they wanted something that would work on W95.

However I don't know of many drivers that worked with W2K that don't work with XP. Did these CDRoms work with W2K?

Possibly others on this board know more?

Stephen Jones
Monday, June 02, 2003

Woops! Win32 Driver Model

Stephen Jones
Monday, June 02, 2003

Thank you EVERYONE for the rich and thoughful feedback.

I'm going to address a few comments that have been posted.  I left this info out to be brief.

I am the only developer, although I am considering hiring a second programmer.  Finding a Delphi programmer can be a challenge, so that's  a business consideration.

I'm not overly concerned about the marketability of my skills.  I don't anticipate working for someone else.  With an 8 year history, my company is doing OK, even in the recession.

Good question.

1.  To use Jpeg images and perhaps MP3 compressed sound.
These programs display a lot of pictures (200 per program) . VB 3 supports only .bmps which get very large for a hi quality image, so we have fairly small images.  The software is for the geriatric population, so we need large, clear images.  To get the larger, clearer images would be about 100 to 200k apiece, or about 20 MB per program.

We have a similar problem with sound.  We use recorded live audio for maximum clarity.  Those sound files can get big.  (One of our programs has 20 MB of sound files)

Program meets user needs better.
Program looks more professional

2. Program extension
About 8 of the programs are all based on one core program (second program I ever wrote).  I want to continue "extending"this to write additional, very similar programs.  This code is now very "brittle" because it wasn't architected for this.

Also, using a more OOP approach might make it easier to extend the program.  I.e., if we can make program #17,which is very very similar to program #14, but just adds a new capability, then it saves us time.  I can do this without OO but it might be more error prone, harder to compartmentailize the code.

(NOTE: our software is educational in nature, so we can have 5 programs based on the same code, but just differing in what CONTENT is in them.  But, often, a new program will ned some slight tweak, like a different way for the user to enter an answer (choosing 3 answers from 3 different list boxes, instead of just one answer from one list box, etc.)

OK, the alure of the OOP approach is also me "giving in" to the C++ snobs who say "you're not a real programmer" if you use vb. My degree is in electrical engineering, not CS, and I only spend about 30% of my time programming, so I'm a little insecure about "not being a real programmer".

So, I'm glad to hear folks on this group say "use vb 6 if that's what you know".  (I have a lot of respect for the visitors of this forum. Joel is a really "thinker" and, so, by association, are all of you ;-)

Lets us easily add more programs, which makes us more money and makes our customers happy.

3. Preparing for the future when Windows won't support old 16 bit apps.
(This isn't pressing and makes us no money right immediately).
BENEFITS: nothing immediate. Saves company if LongHorn windows doesn't support 16 bit <g>. Will also, then, generate revenue from companies who need to upgrade.

BTW, I know of an example of someone that went way overboard in preparing for when windows won't support 16 bit apps.  I know a fellow who wrote his own cross-platform compiler several years ago!!!  It's called KINT


Clay Nichols
Monday, June 02, 2003

RESPONSE TO AnyMouse's comments

AnyMouse :
The issue here is that DELPHI will produce the executible that is the easiest for my company to support. No versioning problems, simpler install, no rebooting, etc.  (And, yes, rebooting is a problem when a 60 year old customer has downloaded your trial and, by the time the computer reboots, has forgotten that they installed it ;-). This has happened even with CD installs.  I've occassionally had customers call to ask where the program "went".  They think the install IS the program.)

So, rather than reinvent the wheel, I thought I'd see what other shrinkwrap programmers were doing.  They face the simlar problems:  simple install, avoiding huge runtimes and dll version conflicts, etc.  Hence the title of my question being addressed to Shrink wrap developers.

Clay Nichols
Monday, June 02, 2003

BTW it may interest the people here that this thread has spawned another thread over at Lambda the Ultimate, the programming language weblog:$7099?mode=topic&y=2003&m=6&d=2

Dan Shappir
Monday, June 02, 2003


I've used Delphi in many commercial projects for the last seven years, along with VB and C++. Your judgement of the merits of Delphi are accurate.

One crummy thing about Delphi is the stupid database engine that is bundled - BDE, the Borland Database Engine. It's a PITA to support and deploy for shrinkwrap developers. BDE  is an inept attempt to replicate the functionality of the MS Jet Engine.

However, there are several good third party alternatives that replace the BDE, though. One is called dbIsam, which (get this) even allows the database engine itself to be compiled into the executable... NO DLLs.

Now, on to a rant. :-)

There is a big conceptual wall of lack of common sense in this industry, and pervasive thick headed propellor headed stupidity about legitimate real world concerns. That is reflected by the fact that most programmers write code for internal customers where the PC can be tweaked in order to compensate for common control conflicts, etc. Your concerns about deployment issues to a mass market are dead on, yet most heads down coders can't conceive of an incapable end user with a "crufty" PC who is so technologically illiterate that *any* challenge to the stability of their PC will result in an unhappy customer.  Yes, they have money to spend. No, they can't understand why YOUR code broke their PC. No, they can't even be coached into fixing it themselves. Yet these people have money to spend.
One thing. Using Delphi will make you conventionally almost unemployable unless you have a strong business focus. "Delphi is dead" certainly applies to the hiring scene. Why? Everyone is scared to death of NOT being a 100% MS shop. Mass brainwashing.

Bored Bystander
Monday, June 02, 2003

Clay -
.Net has all the benefits you ascribe to Delphi.
I wrote a client app to access a webservice and display server status on a windows form. I then sent the .exe (15k) to my computer at work that's a locked-down machine where I had no admin rights. (Though it *did* have the .Net CLR)
Saved the executable to a folder, ran it, and it ran just fine.

So, the difference between Delphi and .Net - 16MB CLR that is a MS standard, version resistant, and a clean install. If that's a show-stopper for you, then Delphi.

If it's not, then you have to look at the resources available for learning and supporting a new language. I haven't spent a *lot* of time looking for Delphi support, but I gotta tell you - there is a mountain of .Net support out there. I solve 99% of my C# development problems with one search on Google. Also, if you're a bibliophile, check out Amazon or your local bookstore for .Net titles vs. Delphi titles.

I agree with others who have pointed out that in pure shrinkwrap nobody cares what language it's written in. So it seems to me the issue is the baggage of the CLR and the assets available to learn whichever new language you choose to work in.


Monday, June 02, 2003


And in your last reply I think you answered your own question. If you need to minimise dlls, components and system calls, delphi is about the only option. Add a single dll to handle mp3 or ogg audio and that should be enough.

As an aside yes I know that .net does away with dll conflict issues and means you can be sure that the correct dll will survive and be used but the .net framework requirement rather offsets this advantage.

Ben Thompson
Monday, June 02, 2003

>> "Delphi is dead" on the hiring scene.

In my area, I have seen no less than 3 jobs advertised for a Delphi programmer in the past 4 weeks.  I certainly wish I knew Delphi.  (Pascal like language no?)  I think the employers can't find people that know Delphi, which happens to be the language the system was originally implemented in, so they convert their systems to MS in hopes of the Utopia that will follow.  May be a good opportunity for me to learn Delphi, if the employer will have it...

You think I'm joking.  I'm not.

Monday, June 02, 2003

Is anyone developing shrinkwrap software in VB 6?
If so, have you had problems with the basic runtime DLLs having version conflicts?

One issue that concerns me is DLL conflicts with the basic runtime components (oleaut.dll, etc.).

I'm not sure if this is paranoid or intuition <g>.

I was very worried about that early on with vb 3 and the problem never occurred, and we had thousands of people install the software.  HOWEVER, vb 3 was 16 so, those files weren't changing much.

BTW, all the points raised are the issues I have wrestled with.  It's not a simple decision, and it is one I will have to (hopefully :-) live with for the next 10 years or so.

(Our vb 3 programs are about 8 years old).


Clay Nichols
Monday, June 02, 2003


One of my thoughts is that shrinkwrap programmers may be driven to delphi for exactly the reasons I've given (problems with the 20 MB runtime, etc.).

My biggest concern with Delphi is how well it'll be supported in the future (by Borland, 3rd party component folks, and other programmers).

So... that is why I asked the question about swrap programmers' language choices.  IT SEEMS like Delphi is the best best if all you care about is the quality of the program you end up with, and ease of distributing it, etc.

Clay Nichols
Monday, June 02, 2003

I'll go with the "Delphi is dead" crowd.

I've been a developer in a variety of roles for quite some time now, and I've seen more Lisp apps than Delphi apps.

No developer I know, or company I know of has any interest in Delphi.

Maybe it's a wonderful tool, but who cares?

Monday, June 02, 2003

> Why are you rewriting, again?

because VB 3 is 16-bit, so it it can't benefit from larger quantities of memory, doesn't support the latest UI improvements, doesn't even support long filenames? Anyway, I'd say VB 6 is the way to go

Monday, June 02, 2003

> Other than the CLR, your app runs as a single .exe and
> perhaps some dll's that don't even have to be registered

yep, no registering required. Just write a manifest for your application that tells the runtime were to find the DLLs it needs, if it needs any

Monday, June 02, 2003

My programs are very, very simple.  We focus on useability, rather than getting terribly fancy.  So, we have no need to access the hardware directly, etc. 

So, we have very little need for extra DLLs, etc.

The only features we might need are:
*Playing compressed sound files (MP3, etc.) that take up less space than .wav

* Very simple database capability (to store results of each lesson when used on a network).

I am considering DELPHI for only a couple of benefits:
1.  Produces a standalone EXE with no 20 MB runtime.
2.  Seems like a very elegant language. "everything is an object".

Monday, June 02, 2003

#2 is satisfied by .Net

Can't argue with #1, other than suggesting that if everyone jumps on the .Net bandwagon, the CLR will often be there before you are.

BTW, the title was "Shrink-wrap developers" - I'm assuming since you express such dismay at the size of the CLR that most of your sales are actually downloads?


Tuesday, June 03, 2003


A lot of people *try* the programs from a dowload. Most people purchase a CD.  Many (perhaps half ?) download before purchasing. Not sure what would happen if it were difficult (nearly impossible at 20 MB) to download.  Some might order our trial CD ($9.50), others we might just lose.
And perhaps a long download will convert more downloaders to trial purchasers ;-)

The *size* of the CLR is *part* of the issue.  It's also how intimidating/complicated it is for the customer to install. It's also the requirement that they have IE 5. (Although IE 5 is preinstalled on Win ME and above).  And there's no easy way( that I know of) to know if IE5 is installed. So, we'd basically punt on anyone with Win 98 or Win 95.  That could be a lot of dollars. Or, we have to continue to maintain two code bases (one for Win 98 and below, the other for Win ME and above).

Our software is usually installed by very non-technical people over 50.  Think of your grandmother. She's our customer.  The install has to be EASY and not-intimidating.  By the time they'd installed IE, they wouldn't remember what they were doing <g>.  Also, if ANYTHING happened to their PC in the next week, WE would be blamed, because it "did so much" during the install.  (They occasionally cast blame our way and we're installing vbx's which I KNOW aren't affecting thier Windows XP operating system.

Perhaps I'm confusing ease of install with ease of USE.  But the issue is that they have to install it before they can use it. And if the install seems hard, they can very very easily get turned off to the program and assume it won't be useable by the patient. (It happens even now, on occassion, with a simple install).

Now that I've written all of that, you've made me think about this some more.  Perhaps if I could detect whether IE is installed and the .net framework can install *siliently* then perhaps .net would be viable.  (I just did a quick search on the former, no luck yet).


Tuesday, June 03, 2003

A little sidestep: You might want to consider using Ogg instead of MP3 as you need a license if you decode the latter:

You could, of course, send MP3 files directly to the Windows Media Player, but it might not be available on your customers computer.

Jan Derk
Tuesday, June 03, 2003

> My biggest concern with Delphi is how well it'll be
> supported in the future (by Borland, 3rd party component
> folks, and other programmers).

You could try the next best thing: C++ Builder.

1. It's C++. With the proper design, you can abstract the UI away and minimize problems, if you need to switch to another GUI framework (see Cons).
2. The UI is as easy to build as in Delphi - actually, the entire VCL (the Delphi framework, GUI and otherwise) is written in Pascal, compiled to OBJs, which are then linked with C++ apps.
3. Based on point 2 above, you can use components written in Delphi's Object Pascal (see Cons).
4. It's as runtime-free as Delphi.
5. You have a lot of C++ libs/frameworks that you may use (see Cons).

1. The universe of C++ Builder's users is even smaller than Delphi. But many of the tips/components for Delphi are valid for C++ Builder.
2. Many Delphi components can't be used by C+ Builder, and you really don't want to invest the time to find out why. If we're talking about commercial components, then you'll get support. Otherwise, tough luck.
3. In order to keep from being tied to C++ Builder, you *must* come up with a good design. The main advantage of C++ Builder over Delphi is that it's C++, and you should be able to reuse as much of your work as possible if you switch to another compiler/GUI framework. This is possible, but, depending on the complexity of your app/system, it could be hard work.
4. While there are a lot of C++ libs/frameworks available, there's little support for using them with C++ Builder. As far as docs/examples are concerned, it's mostly geared towards gcc/VC++. I've spent 2 days to get STLport working with C++ Builder. In the end, it was just a matter of changing the order of #include dirs.

I've tried to be as objective as possible, within my knowledge. I'm a Delphi/C++ Builder enthusiast. I use it in my spare time. However, I've stopped at version 5 of both tools. For a more up-to-date opinion, I recommend a post at the Borland NGs. People are extremely helpful there.

Take a look at .

"Suravye ninto manshima taishite (Peace favor your sword)" (Shienaran salute)
"Life is a dream from which we all must wake before we can dream again" (Amys, Aiel Wise One)

Paulo Caetano
Tuesday, June 03, 2003

Hi Clay,

Interesting topic. When you have the time could you briefly mention the various methods you currently use to distribute your shareware programs?

I would imagine that you post your programs on several shareware websites and you ship CDs via the U.S. post office.

I believe in an earlier post you mentioned that potential customers can download trial versions of your programs from your website. Can customers purchase these programs from your website as well? 

What payment methods do you accept (PayPal, Snail Mail orders, Credit Card processing, etc.)?

How do most of your customers initially find out about the software that you sell? Do you do a lot of advertising?

You mentioned "CD installs" in an earlier post, do you include any written documentation when you ship a CD?

I apologize for all the questions. I do not personally know any shareware authors and have always wondered how many of these individuals were able to profitablly run their business.

Anyways, it sounds like you have found a good niche for yourself. I bet one of the nice things about selling software to elderly people is that your programs probably don't attract too much attention from people who spend their free time cracking and distributing shareware programs.

Just Curious
Tuesday, June 03, 2003

This may be flamebait, but...

JavaWebStart. It solves so many of these problems.
The new SunVM installing only needed components. sweet.

I can't wait till that judgde tells MS to start shipping Java goodness again!

mmmmmmmmmm... java goodness...

Arron Bates
Tuesday, June 03, 2003




>> ... The install has to be EASY and not-intimidating.  By the time they'd installed IE, they wouldn't remember what they were doing <g>.  Also, if ANYTHING happened to their PC in the next week, WE would be blamed, because it "did so much" during the install. 


"Awww, maaaan"... use Delphi.  This application has Delphi written all over it. I think you're getting bound up explaining your legitimate business concerns to people who, for the most part, are NOT in business and who rely on someone else to solve these problems for them in order to get a paycheck.

You won't *ever* get a certain set of geeks to comprehend or acknowledge what you're talking about. Most programmers invent this fantasy of the "properly well informed user with an up to date PC like they ought to have, connected to the internet with a reasonable broadband connection, and with all service packs installed." As though there were a  government agency responsible for licensing PC users and preventing "feebs" from spending money on computers. Right.

Most end users look like idiots to the average programmer who is blind to the concerns of "average users". Again, most end users should be shielded from most programmers by 20' thick lead lined walls.

I've worked in shrinkwrap product development most of the past 15 years. Your concerns are oh so familiar.

Delphi. Don't look back.

Bored Bystander
Tuesday, June 03, 2003

Bored Bystander,

You nailed it.  Nice to have validation on that.
20' lead walls - LOL

Tuesday, June 03, 2003

Language: What about VB 4. Does VB4 automatically upgrade VB3 code?

Distribution: Aren't there applications that combine EXE and DLLs into a single executable file?

MP3 & JPEG: VB4 might be able to handle this, but if not you could use an OCX.

Tommy A
Tuesday, June 03, 2003

Aside from the difficulty in *finding* a copy of VB4 these days, there's really no reason to use VB4 over VB6. Distribution problems won't be any better; probably worse. And if nothing else, VB6 has many more years of bug fixing under the hood.

Chris Tavares
Tuesday, June 03, 2003


Breakfast of champions.

Tuesday, June 03, 2003

VB 4 vs VB 6

... And the VB 6 IDE is much, much superior, as I recall.
I can see no benefit of VB 4 (32 bit) over VB 6.

Wednesday, June 04, 2003

The main thing I was thinking with VB4, was the upgrading of the code. If the upgrade of code from VB3 to VB4 requires no rewrite, then you may get your required features with little work. Upgrading from VB3 to VB5/6 may also require only a small effort upgrading code.

Tommy A
Wednesday, June 04, 2003

I'll second bored bystander: from what I read of your app, Delphi IS the way to go. Support is quite good on newsgroups (google rules). You can embed almost everything in the .exe (including jpgs and oggs or mp3s).

I just finished a multimedia simulation with it that runs on win9x, 2k, xp... not a single line change (and heavy duty graphics).

So, except the 'what were you thinking'-look I got whenever I say what tool I used, it was perfect: the language is easy, the GUI a charm to build, update, modify, tons of add-ons, no nasty bugs (mind you, I didn't say no bugs ;-) ), no install...

Wednesday, June 04, 2003

I'll also chime in with the Delphi crowd.

I've been using Delphi for about 7 years now, and it is great for the type of work you want to do.

If you haven't done any OO programming, you will find the change to Delphi's way of doing things a bit of a challenge at first, and then it will click, and you'll think "why didn't I do this before?" 

As for components, if you need a high quality database component look at DBISAM. 

Also, the suite of TurboPower components was open-sourced earlier this year, so you can use them freely (they are on SourceForge now).

Once you've grasped the concept of Delphi, it's easy to move to Java, C#, VB.Net, or most other OO languages.

Brad Clarke
Wednesday, June 04, 2003

> Also, the suite of TurboPower components was
> open-sourced earlier this year, so you can use them freely
> (they are on SourceForge now).

Yes, but you should tell the whole story. TP was open-sourced because someone decided it was no longer profitable to maintain it. And this is actually Clay's biggest concern with Delphi.

I'm not trying to scare him off Delphi. Just trying to keep a balanced view. While it's true that "Delphi is dead, Lisp rules the world" (please, note the exaggeration) isn't exactly balanced, neither is "Delphi is great, just go ahead".

I, for one, agree with you. However, my relationship with Delphi is an amateur one, meaning, my bottom line is not at stake.

OTOH, Clay is looking for something to bet his shop on. Delphi looks like a reasonable choice, but it has risks, and these should be considered.

Just MHO.
"Suravye ninto manshima taishite (Peace favor your sword)" (Shienaran salute)
"Life is a dream from which we all must wake before we can dream again" (Amys, Aiel Wise One)

Paulo Caetano
Wednesday, June 04, 2003

Hey Chip,
  I suggest taking a look at Clarion.  It's a 4GL with OOP and template-generated code.  It's a totally different ball game compared to C++, Delphi, and the dotNet's.  You'll be hard-pressed to find a language that's more RAD. 

My two cents,

Harley Jones
Thursday, June 05, 2003

*  Recent Topics

*  Fog Creek Home