hi ho hi ho ksh88 has got to go
We don't have sources for ksh88, and never will. ksh93 does everything ksh88 does and more. We should nuke the packaging for ksh88 and add it to the closed-bins exception list.
Updated by Roland Mainz over 9 years ago
Erm... getting access to the sources of the original ksh88 may not be that problematic (it can be provided for building binaries, but it must not be released as open source or relicensed). But this will not help us much since Sun has forked the sources long ago and introduced numerous incompatibilities, unfortunately many things on which scripts like the SystemV package system now relies (for example the infamous change of "typeset -i" to use 64bit math instead of 32bit (which resulted in both broken arithmetric and compatibility (ksh93 still treats "typeset -i" as 32bit integer but added "typeset -li" for 64bit . Sun once had the OpenGroup patch to add "typeset -l -i" to ksh88 but instead opted to increase the datatype width for "typeset -i" instead (because it was easier/faster to implement (see  below, the management thought it is easier to do this instead of replacing s/typeset -i/integer/g in the SystemV package scripts))))).
=The ksh (written for ksh88, but it applies to current and all planned versions of ksh93, too) documentation explicitly says that the alias "integer" always refers to the largest integer datatype available to the interpreter, e.g. 32bit for ksh88 and 64bit for current () ksh93 versions.
=Once |int128_t| becomes more common we'll see 128bit integers in ksh93, too (but implemented via a new typeset option (but the "integer" alias will then refer to the larger datatype (see )))