Run, don't walk, away from any project manager who is intent on deploying a new software system on Windows 98 (this is not MS-bashing but just common sense, if someone were to ask me to deploy a new application on Redhat 5.0 I'd have a similar reaction). The OS isn't even supported anymore, has numerous known bugs and security weaknesses and these days is only justifiable for legacy systems. A manager who doesn't understand that displays a frightening lack of clue and working for him will be painful.

Other than that, from your description I don't see anything that would preclude using Perl for this project. If you run into any performance bottlenecks along the way you can always rewrite critical parts in C or another language, Perl's language interoperability is pretty ok. In the meantime you should be able to get a working system up relatively fast (since you already know Perl) and that talks more than any argument for or against a specific language.

I don't know about anything.net or VB.anything, but I believe Perl is definitely suitable for the situation you described.

As you have a client/server environment, I recommend a Web App running on your office intranet. This eliminates the need for an installation. Preferably running on top of Apache. I think it can be set up on IIS, but I don't have a clue how to do that. For an easy server setup, I recommend xampp [apachefriends.org] which comes with Apache, MySQL, and PHP. You'll also need the xampp Perl add-on. It's all very easy to install. You could download and install everything in less than 30 minutes.

... feeding the script to the stations ...
Does this mean a script which the users read over the telephone? That can all come out of a MySQL table.

I don't know how you get the list of callers into the database, but after you do, querying then and prioritizing them according to time of call should be easy.

In all, I think Perl would be very effective for this task. To make it a nice Web App, you'll need to get up to speed on DHTML stuff. You'll need the following, which all comes with xampp :
Apache
ActiveState Perl
  CGI
  DBI
  DBD::mysql
MySQL

--
-- GhodMode

Just like to add to what others have said... In VB,Java,.NET,etc the standard way of doing client/server is to have a "thick", native Windows client.

In Perl, Ruby, etc. the standard way is to make a Web application. The advantages are numerous, especially with a large user base (no need to install), and especially where you have some control over what browser they're using (make sure no one's using IE4).

With the advent of things such as Rich Text Edits, and AJAX (so long as it's used in a sensible manner) you no longer have a lot of restrictions in the complexity of your user interface.

The fact that you're running Win98 on your workstations is even more of an argument for thin client. You can push most of the processing to a big beefy, clustered, loadbalanced, etc. server running Linux (or Windows server if you must), and install nothing but a browser on the workstations. Any performance issues can be tuned in one place (i.e. the server's OS, the webserver, etc. which are designed to be configured in this manner).

I think once you've made the decision to go with a thin client, then the choice of language becomes much less of an issue.

The second question is how much binary stuff is involved? If there is a lot of binary handling of data, Perl propably wouldn't be my first choice.

On the other hand you could have a prototype done in Perl really fast, so it could advocate Perl further in your company :-) Anyway, the tool chosen for the task has to meet the task's requirements.

A lot of people have already made some good points, I would just like to throw my two cents in. If speed isn't important, I would suggest a web frontent. (I would look into Mason) If faster interaction is required and a web based solution would be too slow (also keep AJAX in mind) I don't know how great a solution Perl would be. You could look at Perl/Tk or wxPerl but without knowing more, Perl may not be the right thing.

I would be hesitant to recommend any VB.net because of the proprietary nature like you recomment but if the project does go that way, look into Mono and I would try to make sure your app works against mono as well in case the company ever decides to look at anything non-Microsoft. I would also take a look at Java. (I consider it a little better than .net.

Oh and one last thing, they also want to run the stations in Win98

Ummm.... I would make a case for at least updating the OS if it all possible. Microsoft has stopped supporting Windows 98 so there will be no bug fixes for it and would be a gaping security hole for your company.

This is currently a M$ shop, which I hope to change, but will not happen over night.

I hate to break it to you but unless you are pretty high up in the chain of command there, you are unlikely going to be able to make any significant changes. At my current position, I work as an Oracle Forms Developer. (just got a new job though!!!!) I was idealistic and thought I could bring about change and at least get this MS only shop running linux on the server end. "None of our clients have asked for it" was the response I got and end of story. I had all sorts of reasoning such as we should look at some open source databases to offer in addition to offering to run our program on Oracle, as well as converting from Oracle Forms to a J2EE environment and offering either Oracle's Application server or an open source one and so on. I had a lot of what I thought were good reasons to switch and not one of them bashed Microsoft in any way. (More along the lines of, let's keep what we have but also offer more things) The response was, if you leave, no one will know any of the new stuff. Which primarily boils down to the fact that my boss (the owner of the company... a small company) doesn't want to learn new things. I finally managed to get them to put linux on one of our old servers that was all but retired and the reason we did this was because he wanted to implement bugzilla but read how much of a pain it is to install on windows.

I also was able to get him to implement Subversion to keep track of the changes we made to our Forms. This was installed on the windows server and recently we were talking and he mentioned how he's thinking of moving our Forms over to source safe. (Where we have our c++ stuff that I don't work on) His reasoning was that he encountered something he didn't know how to do in subversion so he just assumed you couldn't do it. He told me the problem and I said sure, we can do that really easy and I went in and did it. Can you begin to see why I started looking for another job? Anyway, sorry for this rant on a side note but I just wanted to warn you that people don't like to learn new things, especially when it's just a small fraction of the existing company. (I am one of two people here who know linux/unix with a total size of 4 people in the company) So my recommendation to you, assuming you don't want to work with Windows for the rest of your life, is to start looking for another job.