How WinApps are Written (Methods [i] to [iv])

Introduction

At a first glance through books, magazines and websites, there seems to be four main ways to write WinApps.

  1. In C using calls native Windows API functions.

  2. Using Visual Basic.

  3. Using MS Visual C++ and all of the rigmarole that goes with it: the MS IDE, the Resource Editor, AppWizard, MFC etc.

  4. With Borland Delphi.

[i] c and api's

The first of these is the traditional method, used long before Visuals Basic and C++ were even gleams in Herr Gates' eye. This the way in which large comercial programs, the Autocads, CorelDraws and even MS Words of this world were always written.

It's strengths are that what is written is virtually standard C code, with the addition of lots of function calls to the Windows API. This makes it a very flexible method, allowing you to write a program that is either as efficient and compact or as bloated and slow as you and your programming ability allows.

It's big downer is that it can get horrendously complicated, even the simplest little program can require an enormous amount of code and to get a large App working correctly will require huge teams of very highly skilled programmers.

I read somewhere that to write a WinApp in this way takes typically ten times the effort to write one with similar functionality in (for example) DOS, and having dabbled a little with it myself I can well believe that. If you've got some C experience though, it can be well worth having a go at a few small projects, you may lose a bit of hair in the process, but you'll learn a lot about window's internals that may well come in handy later.

[ii] visual basic

The second method blows all of this right out of the window. In fine MS tradition, the idea was stolen (well, bought in this case) from another company, and allows WinApps to be written in a top down manner, as Mrs Beaton would have put it "First catch your Window". You start by designing your Font End, the Windows, Dialogs etc, using some nice snazzy point and click editor. You can drag onto them as many little bells ans whistles as you want, assign each little bit a uniue ID, and then string the the whole lot together with some Visual BASIC code, which by this time has evolved into an almost Fortran99 like Object Orientated language.

The strengths of this is obviously that its so easy to use. A single programmer can very quickly get some simple sort of App up and running in a relativly bug-free state. This is not to be sniffed at, many programs are required simply to work instead of working at a breakneck optimised speed, and if you can get it to that state in one day instead of ten, then that is a huge plus for you.

It's weaknesses are that: [i] it is not very flexible - you're tied into doing things the way that the program manufacturer (i.e. MS) wants you to, [ii] the programs are structured in the way that the VB decides (no tense code here!), [iii] despite what VB programmers may tell you about the fact that VB and VC++ havethe same compiler, you will still not however get the same object code, and so unless it's done by a complete monkey (or MS personel member) an App written in VC++ will normally perform better than one done in VB, and finally [iv] you always need various 'dll' files (such as VBRUN300.DLL) somewhere on the system, so that everyone will know that you're writing in VB and you'll be heavily despised by your programming peers.

[iii] ms visual c++ - appwizard and all!

The third method was MS's attempt to combine the strong points of one and two, but predictably achieved the opposite. Instead of MSVC++ ending up as a quick, flexible way of writing good quality and powerful Apps, it instead became a system that was firstly even more horribly complex than writing in native C, and secondly produced programs that were just as, if not more limited in their scope than those from VB (mainly as it was so difficult to work out what was going on that most people just stuck to doing things in the simplest most straightforward manner.)

Look at why I hate AppWizard so much to see the sorry tale of my early experiences with MSVC. In short, after my first traumatic exposure to it I pretty much left Windows programming alone for quite sometime, until thanks to a few serendipidous discoveries, it gradually dawned on me that there was in fact a fifth way.

[iv] borland delphi

A.K.A Turbo Pascal for Windows. This was Borlands attempt at doing what MS had tried to do with MSVC++, i.e. combine the ease of Visual Basic with the power of a high level language like C++ or Pascal, but unlike MS, they appear to have succeded.

Turbo Pascal (and later Turbo C) was the darling of 80s programmers. Most people (well, me anyway) who used it then remember their introduction to it with absolute joy. It's combination of intuitive IDE (maybe the first one ever) and lightning fast compilation times seemed to take away 90% of the grind of programming and turned it almost into a pleasurable experience. The company started as a one man effort but rapidly grew until it seemed like TP would take over the DOS world! But then sadly everything seemed to fall apart as the company (now Borland) became more coporate and detached from the programmers it had origionally served so well.

Delphi then seems to have been a bit of a saviour for Borland, allowing it to rise up from impending doom. I haven't actually tried this myself but all of the reports I hear of it seem to be extremeley favourable. You can usually tell if program has been written using it by the slightly non-standard dialog boxes that you get, eg. a plain old confirmation box will have a big green tick on the OK button.

Unfortunatly Borland doesn't have either the commercial muscle or apparently the marketing skills of MS, and so, depsite it's obvious high quality, the future of Delphi is not 100% rock solid. Nevertheless, if you are reading this with no prior Windows programming knowledge, and are looking for a way into it, then dumping MS altogether and going to Delphi might not be the worse move you ever make in your entire life.

return to main page

Hosted by www.Geocities.ws

1