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.
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
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::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.
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.
Finish Open Watcom's Win32 API (Done)
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). This project is now essentially completed.
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.
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.
/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.
--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.
The type used for va_list should be re-evaluated. On the x86 platform, all other compilers use a va_list which is a pointer type (usually a pointer to char (Microsoft and many others) or pointer to void (Borland)). Watcom is the only known compiler which defines va_list as an array type on x86. On non-x86 platforms, va_list types which are array types or structs are common. The current va_list definition (char *va_list) is fully ISO C conforming, but causes problems with insufficiently portable 3rd-party source code when passing va_list by value. Note that this would affect only the va_list type definition, not the underlying implementation.
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.
Change Various Defaults
Default tool settings need to be re-evaluated and changed to better suit the current typical computing environment.
For example wasm should default to -fpi87 (and not -fpi) since CPUs without built-in FPUs are becoming rather rare.