DOS to Windows anyone?

DOS to Windows Conversion: a facelift?

What advantages does a DOS to Windows Conversion hold, and why should I fix what isn’t broken?

The title and subtitle indicates corporate thinking as I have heard it, from many of the clients I know who have a DOS product fueling their company’s IT needs. The fact of the matter is that there is apprehension to move from a proven software platform. So why invest?

“The most important development in computer technology since the IBM PC”

What was this magazine cover article describing? Not a DOS to windows move! It was describing the onset and implementation of OOPS programming technology that I glanced at while marking time in a company’s waiting room many years ago! More important than nice windows interfaces and gui screen design! The fact is, that both DOS and Windows can be programmed with “Object Oriented Programming Style” but the odds that your DOS program has this structure is very low. Here’s my spin on the top 10 ways this affects your life:

1. Spaghetti Code VS OOPS:
The older style of dos programming has become known as “spaghetti code” when seen in contrast to oops. The basic structure, layout, and philosophy of coding software changed in a wave of approval that is now standard with every modern programming language.

2. Centralized Coding:
The new style of programming impacts your cost to adjust business rules in a huge cost savings factor. The cost savings come mostly by being able to release new versions without unwanted side effects, and also in terms of IT time to create, test, and deploy.

3. Don’t Fix it if it isn’t broke!:
This stand on computer technology was caused by spaghetti code! With “spaghetti code”/DOS standard technology, a change in business rules was feared because it generally caused an upheaval in operations. With DOS standard technology, your system is comprised of hundreds of individual standalone executables running from a menu structure where each of the programs contains duplicate code to perform similar functions along with its look and feel individually set.

4. Training:
Compare the training necessary to learn the function keys that operate DOS with a simple OOPS menu (generally regarded as a windows menu, but also available in dos) where the function you want to perform “enter payments” is listed from a dropdown menu instead of “doing 4-2-5-7 as my first job in the morning”. A standard oops interface includes a FILE/SAVE option along with standard Microsoft keys that are known to many users, and once trained in them apply to “all windows and web products” – not an exercise in teaching company defined keystrokes!

5. Standardization:
New technology standardizes the look and feel of your individual modules inside one (or just a few) programs, not only from the “windows look” but in the way that the business rules apply such as;
· Whether the company name of customers is labeled “Customer Name:” or “Client:” or “Name:”.
· Whether the company name of customers is “required”, or “capslock”, or “able to be changed by the user”.
· Whether the “Apply Finance Charges” option accepts only a Y/N value and whether the value for a new customer is defaulted to “Y” or not… and how!
· Whether one can delete a payment or not!
· Whether these kind of options must be re-coded for every module or not!

6. Combining Similar Functionality:
One of the most visible changes of a conversion to oops takes similar DOS executables such as “Enter Sales Order”, “Change Sales Order”, “Delete Sales Order”, etc. and moves them into one program. The ability to do this is the power of oops centralized coding and new windows technology which just simply outperforms DOS technology and spaghetti code.

7. Transaction Control:
One of the most basic data related improvements introduced into database technology since most DOS programs were written is transaction control, where “half baked” transactions that partially succeed, leaving a cleanup job for IT are totally eliminated.

8. Speed:
It is true that DOS speed is unmatched by windows technology. It’s not true that this is a significant advantage considering that the reason for dos speed is partially that the transactions do not flow thru centralized business rules to perform their database actions, but simply “write to disk” directly!

9. Maintenance:
Once your system is retrofitted to use oops programming style and structure, changing a business rule such as the way a sales order is calculated is a matter of changing the business layer rule in one spot, instead of updating “sales order entry”, “change sales orders”, “print unshipped orders”, and “update order as delivered”. The tongue in cheek saying for this amazing new technology is; “One changes the business rule in just one spot, and the resulting code is either perfect system wide, or wrong system wide!”.

10. Investing in Technology:
The time to invest in a DOS to windows conversion is overdue. If you’ve waited for the “wrinkles to smooth”, the “bugs to be fixed”, or determined in the past that the “investment” wasn’t worth the result, then I believe you are on the brink of extinction, because the software engineers that understand BOTH the dos and windows technology (and hence the ability to render a modern version from the old true code) are on the verge of retirement! If you wait, it’s a total rewrite to face.

Summary:
These are my top ten reasons to consider a DOS to Windows conversion, and if you started with a goal to port some of your functionality to the web, please consider the windows conversion a half-step there, because most platforms/languages have an extension of the business rule layer that is applicable to the web, or usable by a webapp so that part of your cost is a move closer to internet presence, whether it be customer data sharing, order entry, part availability, or simply customer and prospect information gathering.

About the Author:
By: Peter A Donovan
Applause Software of Boston, USA http://www.applausesoftware.com/
Member in good standing of the NEDC Programming Group: http://www.nedataflex.com/

Peter started his IT career as a combined sales executive/custom application developer the year following the release of the IBM PC. After similar corporate positions, where he was responsible for both Sales and Programming responsibilities, he obtained a position with a software distributor/authorized factory technical service center, where he excelled in custom application development for many different industrial and commercial markets and also travelled throughout the USA, Canada, Europe, and Africa training IT staffs in correct implementation of OOPS foundation coding technology and data dictionary technology.
Currently an independent IT consultant specializing in database software, Peter is actively involved in bidding on new challenges, maintaining a customer base, and publishing a freeware database contact manager “rolodex style” called RoloFLEX as a showpiece for his business.
www.RoloFlex.Biz