DOS Porting Issues
Since we have a few given facts such as:
- OS/2 command line was developed with compatibility with DOS in mind
- OS/2 has support for all known DOS codepages
- OS/2 has a DOS subsystem that is a full version of DOS v5 built in
It is somewhat apparent that porting to and especially from DOS is as easy as it gets, if you cannot get the tools or the time to make a 32 bit version for OS/2, you can create a DOS program that takes advantage of enhanced OS/2 functions such as copy and paste, printer interface etc., in a worst case scenario you can run the original program under the DOS subsystem. Most plain text mode tools port with little or no changes, primarily you will have to keep note of integer and floating point values since a 32 bit system will respond differently than a 16 bit one, and there are minor API differences, not every last DOS call has a 100% equivalent in OS/2.
Graphics libraries
Problems can happen when you are dealing with applications that call windowing libraries and other GUI or graphic libraries for the CLI, the most common libraries actually got ports to OS/2 but there remain a few reasonably common libs that never gained an OS/2 version and it may be difficult to get hold of some of the others now. If you have the source for the graphic library however you may be in luck since the OS/2 command line actually supports most of the graphic modes that DOS has and therefore porting them is relatively simple or even a straight re-compile.
Date, binary values and arithmetic issues
The only other issue to keep in mind when porting is that old software sometimes has artificial limits built into them or assumptions made that made sense at the time they were written but not today. Installers and other programs that query disk sizes in 16 bit values made sense when disk came in 5 to 30 megabyte sizes, but make no sense now with disk sizes in the terabytes. It is best to either remove such code altogether since old DOS apps are so small they are an of inconsequential size even on a small SSD or flash drive or to change any routine to a "is there enough space for this application" query rather than "how much disk space is left" query.
Dates were also commonly calculated using small integers from a set date (typically 1980-01-01 but varies), this meant that the integer value ran out around 2007, some programs assumed only 2 digits for a year which is OK if you are only calculating something that needs current dates such as a PIM, but not good for historical data, some assumed that the program would run in the 20th century only so if they are run now they think it is 1915, so on and so forth.
Development tools like Clipper and dBase for instance supported four digit years out of the box but programmers writing in those two languages commonly just used the last two of the date field when calculating values, this is not a difficult fix but can get a bit time consuming.
Porting tools
- Clipper/dBase/xBase
- All are Clipper style compilers, no-one has been making dBase like interpreted products for a while.
- Basic
- Bywater Basic should be able to cope with code intended for early MS Basic versions
- WDBasic also supports much of the same street basic languages and is a better OS/2 citizen.
- C/C++
- Open Watcom is your best choice overall since it has a number of compatible tools but is otherwise reasonably modern,
- IBM C Set/2 has some compatibility with older Microsoft C and IBM C/2 toolsets, but overall it is recommended that to use Watcom even if that costs you some extra work.
- All M2 for OS/2 vendors provided TopSpeed Modula-2 compatibility packages for their products, but in all cases as separate downloads and not as part of the main package.
- Visual Prolog versions up to 5.1 contained the full Turbo Vision system that could be ported to OS/2 command line, the 5.2 package drops this but it is trivial to make the 5.1 version work with 5.2.
- Most OS/2 Pascal vendors offered some sort of Turbo Pascal compatibility, the open source Free Pascal is actually a TP clone.