Fog Creek Software
Discussion Board

Simple Batch copy – What software would you use?

I have a old program that was written in clipper (before me), and then after a few years some changes where needed. The original programmer was long gone, but we had the source. I of course came along and modified the source code (this was 1993). I did not have clipper, but did use FoxPro and the runtime distribution kit. That means this simple little program in dbase could be changed, and then converted to a STAND ALONE exe file.

The above approach is seems fine. Just this week I was called in by these folks to *modify* the software. My thinking is that this little and simple program should be upgraded to something that is not ms-dos based, and can be supported for another 8 years. Remember, I came along in 1993, but that little piece of code had already been in use for a few years.

The software is a *SIMPLE* little program that copies a few files. These files have nothing to do with database. DBaseIII was no doubt used at the time since the ms-dos batch commands *could* have been used, but they are very poor at prompting the user for a date. Also, a nice language with a if/then/else structure of course made this whole thing a lot easier to write (dBaseIII also has a nice “file exist” function).

The program simply looks for the existence of two files (with a known name). For each of these two files, the user is prompted for a date. When the user hits enter, the files are copied to a archive directory with a format of:  16Mar02.snt. Thus, the language also needs some ability to convert a date from 03/16/02 to the above format.

Of course now the software will need to prompt for 4 files (and thus actually 4 dates). Usually the date will be the same, but sometimes the operator will change several of the dates. At any rate, the default date (today) is displayed, and the user can choose to modify it.

My first choice is to use windows scripting. After all, I want to keep this as simple as possible. My 2nd choice is of course VB. Building a VB install package via the VB package and deployment wizard seems like over kill in this case. I could certainly just create a exe file in VB, and if I say away from any ActiveX controls, then I could simply email the client a nice and tiny exe file. (the resulting VB exe would be less than 50k). Of course not using the date picker in VB will also kind of suck when it comes to entering dates.

Of course windows scripting is even worse from a user interface point of view, and cannot place up a small form that prompts the user for more than *one* date (I am assuming that the only reasonable means here is to use inputbox). In addition, I don’t get any kind of “mask” for the date input.

What should I use to develop this little copy program?
Perhaps this one case where I should continue to use the old program, and simply modify the dbase code?

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Sunday, March 17, 2002

Delphi, no question about it.  Much better than VB, believe me.  Been there, done that, ain't never goin' back!

Having been a Delphi user for about 4 years now (ex-Clipper, ex-VB, exPowerBuilder) I don't understand why people automatically assume that WindowsApp = VB.  Is Microsoft broadcasting some subliminal frequency that doesn't register in my frontal lobe?  More importantly, why do so many people seem to so actively avoid Delphi?  Clearly they have never tried it, despite the "best tool for the job" mantra they so love to spout.

Sorry for the rant, but like every other Delphi user I feel like some elite group with this amazing secret that nobody knows.  Albert, do yourself a favor, expand your horizons.

Also from Edmonton, Alberta, Canada
(Oilers Rule!)

Sunday, March 17, 2002

There are some good little Basic scripting languages that are great for this type of thing.  They are written by enthusiasts and keep things simple.

I'd recommend IBasic for something like this.

IBasic costs just $20, and will only take a couple of minutes to learn.  It creates a small, standalone exe that requires no supporting files.

Ged Byrne
Sunday, March 17, 2002

ActiveTcl (

Anonymous Coward
Sunday, March 17, 2002

i'd go with either prolog or lisp  ;)

Timothy Falconer
Sunday, March 17, 2002

BTW, these kind of questions are why i avoid most newsgroups.  I'm hoping we get fewer "do my homework" requests and simple-task-how-to's here.  That's what USENET is for.  This forum has the chance of being a geniunely useful place to talk about the larger issues of software development & management.

Timothy Falconer
Sunday, March 17, 2002

Actually Timothy, I thought long and hard about posting this question here.

I did in fact post the question for several reasons.

The question from a programming side is *completely* trivial. In other words, the question is not one of a complex algorithm.

In fact, I posted the question because the problem is in its self so very trivial.

However, the question of what tools use in this case is *extremely* complex. This question is about the larger issue of code dependency.

For example, it was suggested that I use Delphi. While I have done a good bit of Pascal, it does seem to be overkill to install, and learn a *large* and complex development system to copy 4 files? It was also not explained to me if using Delphi would reduce code dependency (however, that does seem to be the #1 battle cry of Delphi people). Don’t tell me to use Delphi. Tell me that Delphi does a better job of reducing code dependency, and then I’ll use it!

However, it does bring up the very issue of code re-use. Joel has had a whole bunch of articles on this. This is about the issue code dependency. Perhaps I should have chosen a much more complex problem! In fact, my subject should have been:

“How to reduce code dependency”

The last ten years has seen a march towards the idea of re-usable components. The model has been ActiveX (com). I believe that this kind model is great from a inter-application point of view. In other words writing applications that can be used as a com object was a great leap forward. I do lots of this with Word, Outlook and many others. This is very much a dream come true for Bill Gates. He outlined the world where applications would them selves would be come re-useable components in Byte Magazine more than 10 years ago. I am a very strong believer in this concept, and benefit every day from it (his dream has been true for a some time now). Of course some IT people consider application automation a loaded gun on each persons desk. You just have to look at the Melissa virus to get a taste of the dark side of com automation (Melissa ONLY worked with OutLook, and not OutLook express...due to the fact that OutLook is a com object). Inter-application communication is the #1 thing that MS has over the Linux environment (sure there is Cobra..but until applications are written to this standard, this is of no use to anyone).

While the application interoperability march has been a real bonus, the idea of shared components (not applications) has been a true disaster. If you look at windows XP, it has a huge amount stuff in there to prevent the system dll’s from being changed, or updated by software being installed. We were supposed to be able to use those dll’s are we not?

In other words, the trend in the industry is now swinging back in favor of *reducing* dependencies. Too much code today is breaking. The industry is finally waking up to this.

The .net initiative of course is the extension of the com object model *accross* the net. Again, if the model is used for inter-application communication then this I believe this is good. This model will NOT WORK if it is used to increase dependencies for applications that need simple components ( our code will break when something *across* the net is screwed up on the other end!). I suppose I would support the use of a map control that gets me any map in the world (and those maps come from a .net server). The trade off for dependency here does seem to be worth it.

In fact, the ideal solution here would be for Microsoft to re-introduce a linker for its products (remember those things?). I need to create a stand alone utility with *NO* dependencies. In other words if write using standard tools, then I wind up using ActiveX controls. I believe in this case that I should be able to *link* the code from these objects into a stand alone executable. If the linker could pull the actual date picker code from the mscomcts.ocx then I would be fine. The code I need from mscomcts.ocx is no doubt much smaller then the 700k size that it currently is. I don’t care about 700k. However, if I use 3 or 4 controls for 3 or 4 controls from re-useable libraries, then I now have a very large hunk of code to distribute. In addition I introduce the possibility of now breaking other applications (since the dll’s/ocx that I now must distribute can overwrite existing components). A linker that pulls only the code I need into a nice small .exe is what I need.

The equivalent in the .net would be allow the com object to actually be copied to my PC, and only a *connection* would be established.

Anyway, in thinking about this problem. I going to continue to use the 14 year old dbase code.

As Joel said:
    Don’t throw out the old code. He is right on, and in my case also!

To anyone who though this was a simple programming question, well you missed my point...

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Sunday, March 17, 2002

> “How to reduce code dependency”

You can use the MS C/C++ compiler to make an executables with no dependencies (except dependencies on the O/S DLLs).

C/C++ will still be readable for at least another 10 years ... another 50 years, given there are young C/C++ programmers today.

> Of course not using the date picker in VB will also kind of suck when it comes to entering dates.

I haven't tested it but perhaps shows how to use the Date and Time Picker Controls in comctl32.dll (which you may assume are already on the system).

> Perhaps this one case where I should continue to use the old program, and simply modify the dbase code?

If you do, ensure that the client owns and keeps a copy of the dbase IDE (they'll need it later).

Christopher Wells
Sunday, March 17, 2002

This is why I love Unix/Linux.  We're talking a five line shell script, I'm guessing, yes?  Geez, even LDOS on the TRS-80 had a better job control (batch) language than MS-DOS.

I'd give anything to go back and tell the appropriate Microsoft person (or Bill Paterson):

1. make DOS a decent command interpreter
2. use / instead of \ for directory seperators
3. use LF not CRLF for text files

Timothy Falconer
Sunday, March 17, 2002

As for the larger issue of the appropriateness of the topic... I do see the importance of minimizing hard-wired widget dependencies, and the moving target that is Microsoft.

Your initial post & title seemed to say primarily "here is my situation, what would you do", not "what do you use for simple tasks to minimize dependencies".  The latter point is in there, but it's kinda lost in the description of the problem.

My apologies if my words caused offense.

Timothy Falconer
Sunday, March 17, 2002

If you want to know something about batch files, try

Christopher Wells
Sunday, March 17, 2002

Actually, Windows scripting (vbscript) is just fine from a file copy point of view. The scripting language can even define and use applications as a com object. This means you can open applications, and use code from that application. This is great, and in fact for scheduling and automating certain kinds of software it is unbeatable. The ability to use applications as a com object in a batch file can boggle the mind. You can launch Excel, do some calculations, load, read sheets and print some stuff, save it, and then launch the next application in the batch file. As long as the application is written to the com standard, it can be automated via vbscript.

In fact it makes vbscript *too* powerful and dangerous in many cases. Some admins are now starting to ban the use of vbscript.

In other words, the lack of features in windows scripting is probably second to none. For roll out of software in a network, I can’t think of anything better.

The real problem here is not really the script part, but the part that needs to ask the user for a date. It should default to today's date, and also have a nice input mask so the user does screw it up. It should also not allow a user to enter illegal dates. Also, notice the requirement that today’s date of 03/16/2002 be converted to a file name of


In other words, your scripting language better be able to convert 03 to the string text "Mar", or you will have to start writing some code! Vbscript has good bunch of string manipulation stuff (much the same as vb).

Thus Vbscipt does do a fine job in this area. However, it sucks on the user input side. The old dbase code does 1 thing well, and that is prompt the user for a date with a default, and checking!

By the way, I would probably change the whole file copy mess, but then again, that software was built around 16 years ago. This system was upgraded to run on Linux only this year, along with Windows clients (before that, they were green screen terminals via rs232) The only pc all these years was a billing submissions pc with a modem.

The software (Medical billing system) is still very old. We did dump the old text word processor and now have integrated ms-word into this system (I was called in since I happen to be fluent in the database system running on the Linux box, and also with windows development). Ms-word was again great here since when you hit alt-f11 in word, up comes the visual basic IDE. I suggest you all try hitting alt-f11 in ms-word if you have never done so. Imagine, every single copy of word has visual basic! This goes back to Bill Gates dream of each piece of software being a re-useable and *programmable* component.

Well, folks we are living in this dream. Windows, and their applications are now com programmable objects. The problem is that some people would call this something other than a dream.

Actually, as mentioned I do love com. It enables amazing automation, and inter-operability between my applications, and stuff like the ms office suite. Everything is simply a programmable and re-useable object.

It is also why I believe that Linux is not ready for prime time (at least on the desktop). Without com, most of the above stuff can be done in Linux, but it is a real pain. Thus Linux does not even come close to windows when you try and integrate applications.

Of course the Linux/com debate does not belong here in this thread!

Albert D. Kallal
Sunday, March 17, 2002

The problem with VBScript automation is that it requires Windows Sripting Host.  Only users with an up to date browser or IE installed can use it.

Since were talking about a site that is still using dbase scripts, Its not safe to assume that they still haven't got a few pre-pentiums still in action.  Place I worked at last still had 386s running Windows 3.1.

I think the question is a valid one, and not just a simple programming question.

Is there an alternative to the increasing complexity and dependancy?

It becomes even more of an important issue with the .Net juggernaught.  Is there any future for the 312k stand alone executable?  Can we really do without it?

Ged Byrne
Monday, March 18, 2002

Delphi would appear to be a good fit for this sort of task, it's not going to require any additional DLLs or similar nonsense.

I wouldn't agree that it was large or complex. Delphi is far easier to get into than any equivalent product and even a newbie should be able to knock up what you're requiring in an afternoon. But if you don't already have it, or Pascal experience, it's certainly overkill to get it just for this.

In this situation modding the existing code makes a lot of sense and certainly gets the job done NOW rather than later. If it won't be touched for another decade or so it hardly matters what dev tool is used, it'll always be out of date when you come back to it.

Monday, March 18, 2002

I think given the simplicity of the problem, and the "no outside dependencies" requirement, I'd go for C or C++, and make sure the executable is statically linked.

Any kind of ActiveX/Delphi/WSH/Perl (my 1st choice)/Prolog/Lisp solution would make it hard to avoid dependencies, and would require that the development environment still be around in 5-10 years. 

By using "vanilla" C/C++, you should be insulated from that kind of problem.

Mike G.
Monday, March 18, 2002

VB would suck for this because it is a pain (in my experience) to install VB apps.

I'd dump the dbase app because dbase is going to be harder to support as time goes on.

If you know VC++, I'd suggest writing a *simple* VC++ program to do the task. Installing simple VC++ apps is easy.

While writing such a simple app in VC++ might seem to be overkill, over time, you'll likely spend less time supporting the app and it may be easier to pass the support to someone else.

Monday, March 18, 2002

Mr. Kalall,

You seem to have to most pragmatic approach of anyone on this thread.  I suggest you ignore the babble you've received as repiles.  Can't the user just be asked to enter "Mar" instead of '03' ?  I suggest you make a simple DOS script that takes the final file name as a cmdline param.  ($1, $2, etc)  You will be DONE coding sooner than it will take you to read the rest of my RANT....

The replies here are are the PARAGON of what is wrong with software development today.    Almost EVERYONE ignored his MAIN PRIMARY REQUEST, which was to keep it simple.  Everoyne has their own damn agenda, and solving the user's problem is of secondary importance.  That is why the IT boom will be going down the toilet soon enough.  Companies have wasted their last dollar on superflous bullshit developement.

Many of you reccomended a GUI DEV TOOL (VB/Delphi) to do a FREAKING FILE COPY....  You idiots should be fired, as you are incompetent software designers.    Stick to being code drones, handed specs.  And Reccomending enterprise level .NET is this taken to a furthur LAUGHABLE extreme.  I'm shocked no one suggested making XML based JavaBeans webservice to do the file copy.

Others suggested C++.  Yes, no install dependency, but to get into hardocre OO for a freaking file copy?  The issue of staff knowledge and maintainability is also an issue here.  Way off base, if you ask me.

Anyone reccomending Unix is simply an idiot who has never had a real job that solved problems..  He's not gonna redo his god damn OS just for this file copy.  Get a clue.

Anyone reccomding esoteric random shit like TCL, prolog, lisp.  Get a clue.  You are a detriment to whereever you work.  MAINTAINABILITY is the core of the posters INITAL problem, for christ's sake! 


Monday, March 18, 2002

>i'd go with either prolog or lisp ;)

Hmm... see that little winking smiley at the end there?  The fact that two different people took me seriously is pretty incredible, even without the smiley.  It was a joke!

Also the misunderstanding about Unix/Linux.  I was just bemoaning the lack of a decent command-line interpreter in DOS, not suggesting anyone change their OS.

Now that I think about it, I'm surprised someone didn't think I was suggesting he switch the client to using a TRS-80!

Timothy Falconer
Monday, March 18, 2002

Despite the ranting, I think Bella's got most of this down.

Use whatever you know, it's not worth the time it'll take to learn something new.  Don't worry about whether it can be maintained or not, because if the language is obsolete in a few years you can rewrite the thing in an hour.

If the language you're using can't make a staticaly linked program like this in under a meg, there's probably something wrong with it, but oh well.  Is it really going to matter if the file's 50 kB or 1.4 MB?  Will they even notice?  Similarly, if you need a full-blown installer for the program there's probably something wrong, but will the client refuse to use it, or think much less of you if you do?  Everything seems to come in an installer these days, even when it's just a self-extracting zip file (aparently it can't be assumed that I can unzip files by myself, or maybe that would look unprofesional).

Finally, I can't resist commenting on "your scripting language better be able to convert 03 to the string text 'Mar', or you will have to start writing some code!"  That code is pretty trivial, so I wouldn't make this a major criteron for your language selection.

Michael Chansky
Tuesday, March 19, 2002

>Many of you reccomended a GUI DEV TOOL (VB/Delphi)

Whoah, easy tiger!  Forget your Ritalin this morning?

In addition to being (IMHO) the greatest GUI tool on the planet, Delphi also enables you create console applications by either using the {$APPTYPE CONSOLE} directive, or going into Project Options and clicking the "Generate Console Application" checkbox.

I agree with your sentiment that sometimes a console app is the best option.  I have a number of them in use, all created with Delphi.  I get the extreme power of Delphi combined with the elegance of Object Pascal all wrapped up in a relatively non-complex console application.

>You idiots should be fired, as you are incompetent
>software designers.

Lets put this into perspective:  I suggested a tool that does both GUI and command-line, using a common language in either case.  Further, my suggested tool creates standalone EXEs that require no runtime support such as VBRUN*.DLL.  And I'm the incompetent idiot?

Tuesday, March 19, 2002

I am sure there will exist a simple OCX that would achieve this brainlessly.

Tuesday, March 19, 2002

Indeed - what Sonny said.

Fun to read a rant based on ignorance though.

Tuesday, March 19, 2002

Storm in a tea cup.

Tuesday, March 19, 2002

Wait, why was the HTML page with some VBscript that has the logic nixed? 

Was it version dependence?  User must have IE installed?  Is that an acceptable requirement (since IE is std on windows)

Tuesday, March 19, 2002

While a simple DOS script might seem to be a reasonable solution, it probably would not be acceptible to most users (it would not fly in my company or for our clients). A simple GUI program might seem to be overkill, but most users would find it easier to use than a console app.

Thus, Bella seems to be completely ignorant of what pretty-much everybody else here is aware of.

Tuesday, March 19, 2002

Is there any way to get around requiring any user input at all ?  (The user is basically entering in the date every day.)
Once your script can determine the date, perhaps the entire copy can be automated, via the windows services scheduler...

Tuesday, March 19, 2002

I could probably eliminat the need for the date prompt...but on occasion it *does* need to be changed!

>”Storm in a Tea Cup”

What a nice way of putting things. Yes, this is a small problem.

Interesting, that I am willing to use Vbscript here. All of the client PC’s are less than one year old (all new dells...those little tiny bookshelf things). Since all these new PC’s were replacing some Wise Terminals, several have flat screen LCD monitors.  Those color monitors are *much* larger then our old slim Wise terminals, and would cramp up the front area too much).

Thus, the oldest OS and pc is now less than one year old. There are a few vbscripts in use now. The users, and the system are not connected to the net, nor do use the net, or email as part of the work routine.

Thus, virtually all hardware was replaced this year. The software was moved from a very old box to the Linux box (Red Hat). The RS232 cabling was dumped and now is a network. Access to the software running on the Server is via a terminal emulation on the windows pc’s. Thus, they all have PC’s, but the software is still text based. Of course a portion of the billing system now does use Word, and code was written to integrate Word into the system. The terminal software can launch Word, and at that point my software takes data from the Server and builds some patient records (information is transcribed from a Dictaphone into these patents records, part of which are now word. Hence billing data and codes come from the Linux server). These files are then saved in a document area, keyed to the patient.

There is only the ONE small dbase script. Looking at this situation, I should get rid of this dbase thing once an for all. In other words, I think that creating a VB package is not too bad. As long as I place the package in a directory, then it can be re-installed when that windows PC surely will crap out (however, a stand alone exe needs no install, and can be *restored* from a back up). In fact, if I do switch this over to VB, then I actually will have to have LARGE letters on the form explain to use the TAB key in place of the Enter key on this form. Since all of the current software still uses the Enter key to move to the next field. Of course any of you who have to mix legacy software, or have migrated users from Green screens to windows know what I am up against!

I was quite surprised by several people’s suggestion  here to have the user type in the Actual date. For more than 10 years the Terminal software would launch this tiny dbase script, and the user could hit Enter 3 times, and be done. (the 2 dates default + a ok prompt default).  Introducing the idea that user start typing in the file name/date is for sure a no go. Every single user would be surprised that the NEW software requires more typing than the old. Not to mention training of users on the correct file format. In other words, someone would have to COMMUNICATE that the correct file format is 16Mar02.snt. In fact, if I make too much of change for this simple little task, then training users will come into play (not to mention the updating of documentation and the how to’s).  You folks have heard of procedure manuals...have you not? Users DO NOT have to know that 16/04/02 gets converted to 16Mar02.snt. In fact, they probably don’t care or even know what/why happens here!

This simple change to the system should NOT require a phone call to support. If I use VB, then the Enter key also DOES NOT move to the next field. This is actually a problem!

I can see it now. Hey, Sue how do we archive the billings for transmission to the government. Oh, lets just ask Julie down the hall. Julie does not work at this station anymore, but she did use the system for a good 5years. She also used to train people so she will know.

So, Julie on phone (intercom #233) simply states you select the archive option, and a prompt comes up. You just enter a few times and you are done. Sue replies back...but the Enter key does nothing now. Julie shrugs her shoulders...better call the tech people...something is wrong with the software....

Anyone who has read Joel’s comments on software, and the example of pushing a shopping cart around with a crappy wheel will understand this. There is no reason in the world that changes to my software should cause *increased* difficulty to the user. The cost  of any support call will out weight the cost of the actual change to the software!

Also remember, that any procedure that can introduce a error into the system has to be though of quality control issue. Filing patient info to the wrong person can result is a huge mess, not to mention lost time, and legal issues (diagnose information going to the wrong patient is a night mare).

The changes to the software were tested for 7 days. After we moved, we found one patient doc got miss filed. Needless to say, 2 clinics were shut down for a Saturday, and all available staff was called in to check each and every record for the week. People don’t like giving up their Saturday like that. Worse is he possibility of miss-filed information. Is that a cold you have, or a tumor? I will not even being to think the liability here.

Procedures in place caught this mistake, but the software was modified to prevent the possibility of this happening in the future. This could not happen with the old word processing system, but the introduction of Word did allow this. Now the code in ms Word will not let users screw this task up (the save location and doc ID is handled by my code now).

At the end of a day, a task can seem trivial. However, a trivial mistake can result in very much damage to your client. If my reservation software screws up, then people probably will not die, but it certainly can ruin their ski holiday, and I am not even going to let that happen!

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Tuesday, March 19, 2002

So what was the verdict on distributing an HTML/javascript file to each user's machine?  I'm not sure of the "sandbox" limitations with regard to file security/permissions, but I don't think this is an issue.  You'll get a nice GUI & scripting to do date conversions/defaults....

To automate, maybe you can even add it to the scheduler, and have your javascript does a form.submit() on the open event...?

Tuesday, March 19, 2002

I'm not arguing about using Delphi to solve this particular problem, but I feel the urge of point some facts:

1) Delphi IS a _really big_ development environment, at least from the size point of view.
2) Executable programs compiled with Delphi doesn't need any extra DLLs by default. You can create executables that depend on VCL dlls, but usually you don't need that.
3) Delphi executables are medium sized (around 500-700kb)
4) Delphi supports CORBA _and_ COM.
5) Combined with Kylix you can create applications for Windows and Linux with ease.

What else can I say... I love Delphi. Please, note that I'm not urging anybody to solve a small file copy problem with it.


Albert pointed a very interesting issue here, about people being used to press Enter instead of Tab to move between fields... that's a difficult choice, but if that people are in contact with modern apps, they can get used to press tab in a relatively short amount of time.

And if you want a default date, that's one keystroke (default OK, just press enter) instead of your three keystrokes.

Sorry for my english :-)

Leonardo Herrera
Tuesday, March 19, 2002

Will ... not ... write ... this ... thing ... myself ....

Seriously, it'd take less time to write it than to sift through this topic. I'll admit there's a sadistic thrill to watching everyone argue about the philosophical underpinnings of simple console apps, but really!

Timothy Falconer
Wednesday, March 20, 2002

>If I use VB, then the Enter key also DOES NOT move
>to the next field. This is actually a problem!

In Delphi you can use the Enter key as the Tab key with the following code in the OnKeyPress event:

If Key = Char(VK_RETURN) Then Begin
  Key:= #0;
  Perform(WM_NEXTDLGCTL, 0, 0);

You can put the code in individual OnKeyPress events for each edit control, but it is cleaner to create a single OnKeyPress handler and share the handler.  Drop me an offline message if you want samples.

Wednesday, March 20, 2002

Are you Delphi coders actually EMPLOYED?? 
Who on  EARTH uses Delphi?? 
You must be at the last remaining firm that does...

Wednesday, March 20, 2002

> Are you Delphi coders actually EMPLOYED?? Who on EARTH uses Delphi?? You must be at the last remaining firm that does...

So far as I can tell from the population I hang out with, most self-employed programmers use it.

Christopher Wells
Wednesday, March 20, 2002

Did u know that net2phone, homesite, hotdog and thousands of other programs use delphi. The big guys don't tell that they use delphi just because projecting the MS part gives more confidence.

Thursday, March 21, 2002

Umm, has the Fox .exe suddenly broken?  Has something changed that means future users would never understand it?

If you want to make it all new with a fresh coat of paint build exactly the same source with Visual Fox if you want.  But it doesn't sound as if the users really care.

Longevity is not a sin.  It just means it does what's needed.

Simon Lucy
Thursday, March 21, 2002

Of course reading all the comments to the original made me forget the original post and that it needed updating.

Mea culpa

Still, if you still have, or they do, Fox 2.6 do the changes in there, the users won't need to learn anything 'new' and it can be forgotten for another 10 years.

Simon Lucy
Thursday, March 21, 2002

*  Recent Topics

*  Fog Creek Home