Version 2 Todo List
From Open Watcom
Here is a list of items to do in a (so far purely hypothetical) Open Watcom 2.0 release. The changes are expected to break backwards compatibility in more or less subtle ways.
C++ Related
This section contains a number of C++ related features or enhancements that might be appropriate for Open Watcom v2.0.
Complete Template Support (Mostly)
When Open Watcom C++ went open source it was quite far behind the standard in terms of its support for templates. Gradually modern template support has been added, typically a little bit at a time. Currently (2007-04) work is in progress on providing support for several important missing features: member templates, explicit template arguments for function templates, lazy instantiation, and proper support for typename to name a few things. Once these features are in place the compiler will be reasonably conformant to the standard in the area of templates support.
Complete OWSTL (Mostly)
Open Watcom's implementation of the Standard Template Library has been ongoing since the development and release of v1.4. Finishing OWSTL to the extent of having all the major containers and algorithms implemented would be a good goal for Open Watcom v2.0. Some of the more obscure and less used portions of the STL, such as valarray and vector<bool> do not need to be implemented for a 2.0 release.
Complete IOStreams Overhaul (Mostly)
The Open Watcom C++ library also needs a new, modern version of IOStreams. This goes along with the mostly complete STL implementation; without an updated IOStreams certain components of the STL, such as I/O operators for std::string and std::complex are not available.
Improve Exception Handling Efficiency
The exception handling mechanism used by Open Watcom C++ is not as efficient as it could be. See bugs 333 and 334. As a consequence of this, exception handling is turned off by default; a situation that is awkward for users of the standard library. Ideally exception handling would be improved so that it would be reasonable to enable it by default.
Tools
This section contains possible updates to the Open Watcom tool set that might be appropriate for Open Watcom v2.0.
Fix C++ Support in the Browser
The Open Watcom browser has not been usable with C++ for a long time (due to bugs related to name space support---probably these bugs have been in the compiler since the days of Watcom v11.0). It would be nice to get this fixed for OW v2.0 so that the browser once again works as it should for C++ programming.
Trap File Interface
The debugger trap file interface could use some modernization. A project to convert the trap file to PIL (Process Interface Layer), similar to MAD and DIP interfaces, was started at Sybase but never finished. The new interface should include at least the following changes:
- Support for 64-bit and possibly larger addresses
- Provisions for debugging multiple processes simultaneously
- Interface for user-controllable interception of signals/exceptions
- Support for target-specific extensions (extra commands, perhaps menus/dialogs)
- Possibly support for byte swapping at the interface layer.
The new interface should be designed such that it could be used for piggybacking on kernel debuggers. Some of these extensions could be bolted onto the existing interface, others require fundamental changes.
Support Filenames With Spaces
Every tool provided should support filenames containing spaces. There is already existing support in some tools, but this should be extended to all tools. One solution could be to use common command line parser.
Other Items
Finish Open Watcom's Win32 API
The Open Watcom project has its own OS/2 API but has been using the Win32 API headers from the MinGW project. We have recently begun building our own implementation of the Win32 API headers (in order to have greater control and shorter bug fix response times). The completion of this project would also be a good addition to Open Watcom v2.0.
Integer Argument Passing
Currently all arguments of a rank lesser than int are converted to int. This is inefficient, but avoids problems with unprototyped functions. If arguments were not extended, mismatches in prototypes would be exposed, potentially breaking existing (incorrect) code.
Remove Limitation of 8.3 Filenames
Remove limitation of that Open Watcom's headers must match 8.3 convention. This is only required to install on FAT partitions and in there we could provide ZIP/TAR style packaging that contains all needed headers in their full length names. And then compilers should scan this package when looking for headers and package is provided in INCLUDE line.
Example:
set INCLUDE=%WATCOM%\h;%WATCOM%\h\fat_hdr.zip;%INCLUDE%
And fat_hdr.zip would contain either all headers or headers not matching old 8.3 convention.
Remove Old DOS Tools From Build
Open Watcom source should be compilable on non-DOS platforms. The only remaining tool not available in source form, albeit a rather complex one, is WGML (used for generating online documentation). However, build tools are not strictly related to compiler release schedule.
Redesign Compiler Command Line Arguments
Currently Open Watcom's compiler parameter space is a bit polluted. This could be redesigned so that adding future architectures and options to compilers could be made easier. Backward compatibility could be preserved. Remove compatibility for "/opt/opt2/opt3", require users to write them as separate as in "/opt /opt2 /opt3". Unify parameter parsing between different targets.
Examples:
/arch=x86-64 /autodep="filename with space.mk" /debug=none
Unify Help Screen Displaying
Currently many Open Watcom tools requires different parameters to show command line help. This should be unified between all tools where possible.
Examples:
--help -? /?
Rework C Compiler Warning Levels
Currently there are too many warnings cramped in a single warning level. Somewhat more even distribution would be helpful. The default warning level should only flag problems that most likely indicate incorrect code, while the lower level warnings should diagnose portability and similar issues which are probably not errors but tend to indicate code that makes unwarranted assumptions. Basically the default warning level should not overwhelm users with too many warnings, while the highest warning level should be quite picky.
Make Incompatible Library Changes
There are some minor issues in the C runtime library that should be changed, but the changes won't be backwards compatible and will break existing libraries and possibly existing source code.
For instance, the definitions of flags in fcntl.h (O_TEXT, O_EXCL, O_NOINHERIT, etc.) should match Microsoft compilers - there is no good reason why these flags should be different. Unfortunately, changing the flags may break existing code in a way that would be difficult to detect and therefore should be postponed for a major release.
Reorganize the Source Tree
The source tree should be restructured and many directories renamed. Notably the 'bld' directory should be probably renamed to 'src' and the 'rel2' output directory ought to be called 'out' or something along those lines. The 'docs' directory should perhaps be moved under 'bld ('src'). Some of the projects should be renamed, eg. 'ndisasm' -> 'disasm', 'nwlib' -> 'wlib' etc.; some confusing or non-descriptive project names should be perhaps reconsidered ('trap', 'viper'). Other projects might be merged or split. The goal should be clarity and simplicity.
Reorganize the Output Tree
The output directory tree should be reconsidered/restructured/updated as well. Specifically, the 'binxx' directories should only contain files specific to a platform. Instead of dumping all shared files in 'binw', we should have a 'common' or 'shared' directory to store debugger configuration files, wlsystem.lnk, executable stubs, possibly DOS extenders and .ihp help files, and similar files that are used by our tools but not usually executed (and hence not necessary to be on PATH).
The 'sample' and 'src' directories probably ought to be merged or at least reworked, since both contain mostly sample code. Possibly the header file and library directories should be reconsidered as well.
