OS/2 may not be useful to you, but believe it or not it is very much alive and well in corporate use all over the world. Did you know that over 80% of the worlds ATM (Automatic Teller Machines) run OS/2? And that something like 50% of all banking systems run OS/2? And a large portion of voice mail systems run OS/2?
Sure OS/2 is dead as far as a consumer level OS is concerned, but it is far from dead in the corporate world. And if it is used by corporations, then someone has to write programs for it, and Watcom is one of the best compilers around for doing just that.
BTW, the US Navy's new smart ship runs OS/2 on a number of the machine, with no NT systems in sight;-)
> It is unfortunate that it requires some proprietary components in order to function.
The only proprietry components are the SDK's, not the tools that are used. Included in the Open Source release will be full source code to *all* utilities such as the compiler, linker, librarian, assembler, resource compiler and much more.
We are planning the Open Source 1.0 release to require the 11.0c compiler in order to build, but be able to rely on freely available SDK's to actually produce programs. Ie: you can download the Open Source 1.0 official binaries and the Microsoft Platform SDK (from the M$ web site), and start happily writing Win32 programs.
One useful addition to the project would be additional support for non-OMF and non-PE executeable formats. Ie: support for ELF would be nice, so that it can directly generate Linux executeables.
So in other words, to compile the 1.0 Open-Source version, you need the commercial 11.0c version. So everyone run out and buy the 11.0c version for ~$200 so you can compile your free Open-Source version.
Actually you will find it difficult to buy the 11.0b compiler commercially these days. However for developers who wish to join the Watcom developer team, we do have rights to provide copies of the compiler specifically for Open Source development purposes.
If we could simply make 11.0c freely available on the web with all required components, we wouldn't have this problem. But remember that Watcom includes the Win32 SDK, MFC and many more components that are licensed and cannot be simply re-distributed on the web for free.
Actually the code we will be releasing already includes a near production level quality compiler for the DEC Alpha chipsets, and the beginnings of compilers for MIPS and PowerPC processors. Watcom has since day one been completely CPU retargettable, and is very cleanly written internally.
Hence it is definately not specific to the x86 processor architecture, and in fact I do believe it was originally developed on non-x86 systems many years ago.
Hence it is highly possible that the Watcom compilers may be ported to other CPU architectures.
Actually the Open Source 1.0 compiler will include full support for both 16-bit and 32-bit DOS development out of the box. Including a commercial grade DOS extender (CauseWay, which is now public domain).
Hence your wish has now come true (not to mention the awesome debugging environment for 32-bit DOS development)!
Right now the only real compiler on Linux is GNU C. There are moves afoot to bring the Borland and Metrowerks compilers to the Linux platform (Metrowerks for Linux is currently GNU C based), and I expect a Watcom port will not happen also.
Some might think that a port of the Watcom compiler to Linux would be a waste of time, since GNU C is already available. But consider that some developers may wish to port code to Linux that was previously developed with Watcom, and doing the port with the same compiler is a *lot* easier than doing a complete port to a whole new development tool chain!
Also don't forget that with Watcom going Open Source, there is also a mostly MASM compatible assembler included (WASM), which means porting existing DOS/Win32/OS2 assembler code to Linux will be a lot easier.
You are of course referring to the GNU C compiler. GNU C was never a mass-market commercial compiler, but has been Open Source since day one. The press release refers to the fact that no othe commercial mass-market compiler has even been turned into an Open Source project. Don't get me wrong, GNU C is a great compiler, but it has completely different roots to the Watcom C/C++ compiler. For developers with an existing investment in the Watcom compiler, switching to GNU C would have been large and difficult task. Now that Watcom C/C++ is Open Source, it's future is ensured and users can continue to use the product and not be required to find a replacement.
On top of that the Watcom compiler supports many environments that GNU C does not support, such as 16-bit DOS, 16-bit Windows and 16-bit OS/2. This may seem like a useless feature to many developers out there, but believe it or not people do still use and develop for those platform!
Also for companies like ourselves, switching from our Watcom based development environment to a GNU C based environment was not an option we were interested in pursuing (lack of 32-bit DOS remote debugging, totally different inline assembler and more makes it a painful switch).
Slashdot Mirror
> OS/2? Are you people on crack?!!!
;-)
OS/2 may not be useful to you, but believe it or not it is very much alive and well in corporate use all over the world. Did you know that over 80% of the worlds ATM (Automatic Teller Machines) run OS/2? And that something like 50% of all banking systems run OS/2? And a large portion of voice mail systems run OS/2?
Sure OS/2 is dead as far as a consumer level OS is concerned, but it is far from dead in the corporate world. And if it is used by corporations, then someone has to write programs for it, and Watcom is one of the best compilers around for doing just that.
BTW, the US Navy's new smart ship runs OS/2 on a number of the machine, with no NT systems in sight
> It is unfortunate that it requires some proprietary components in order to function.
The only proprietry components are the SDK's, not the tools that are used. Included in the Open Source release will be full source code to *all* utilities such as the compiler, linker, librarian, assembler, resource compiler and much more.
We are planning the Open Source 1.0 release to require the 11.0c compiler in order to build, but be able to rely on freely available SDK's to actually produce programs. Ie: you can download the Open Source 1.0 official binaries and the Microsoft Platform SDK (from the M$ web site), and start happily writing Win32 programs.
One useful addition to the project would be additional support for non-OMF and non-PE executeable formats. Ie: support for ELF would be nice, so that it can directly generate Linux executeables.
Watcom VI source code will be included as far as I know.
So in other words, to compile the 1.0 Open-Source version, you need the commercial 11.0c version. So everyone run out and buy the 11.0c version for ~$200 so you can compile your free Open-Source version.
Actually you will find it difficult to buy the 11.0b compiler commercially these days. However for developers who wish to join the Watcom developer team, we do have rights to provide copies of the compiler specifically for Open Source development purposes.
If we could simply make 11.0c freely available on the web with all required components, we wouldn't have this problem. But remember that Watcom includes the Win32 SDK, MFC and many more components that are licensed and cannot be simply re-distributed on the web for free.
Actually the code we will be releasing already includes a near production level quality compiler for the DEC Alpha chipsets, and the beginnings of compilers for MIPS and PowerPC processors. Watcom has since day one been completely CPU retargettable, and is very cleanly written internally.
Hence it is definately not specific to the x86 processor architecture, and in fact I do believe it was originally developed on non-x86 systems many years ago.
Hence it is highly possible that the Watcom compilers may be ported to other CPU architectures.
Actually the Open Source 1.0 compiler will include full support for both 16-bit and 32-bit DOS development out of the box. Including a commercial grade DOS extender (CauseWay, which is now public domain).
Hence your wish has now come true (not to mention the awesome debugging environment for 32-bit DOS development)!
Right now the only real compiler on Linux is GNU C. There are moves afoot to bring the Borland and Metrowerks compilers to the Linux platform (Metrowerks for Linux is currently GNU C based), and I expect a Watcom port will not happen also.
Some might think that a port of the Watcom compiler to Linux would be a waste of time, since GNU C is already available. But consider that some developers may wish to port code to Linux that was previously developed with Watcom, and doing the port with the same compiler is a *lot* easier than doing a complete port to a whole new development tool chain!
Also don't forget that with Watcom going Open Source, there is also a mostly MASM compatible assembler included (WASM), which means porting existing DOS/Win32/OS2 assembler code to Linux will be a lot easier.
You are of course referring to the GNU C compiler. GNU C was never a mass-market commercial compiler, but has been Open Source since day one. The press release refers to the fact that no othe commercial mass-market compiler has even been turned into an Open Source project. Don't get me wrong, GNU C is a great compiler, but it has completely different roots to the Watcom C/C++ compiler. For developers with an existing investment in the Watcom compiler, switching to GNU C would have been large and difficult task. Now that Watcom C/C++ is Open Source, it's future is ensured and users can continue to use the product and not be required to find a replacement.
On top of that the Watcom compiler supports many environments that GNU C does not support, such as 16-bit DOS, 16-bit Windows and 16-bit OS/2. This may seem like a useless feature to many developers out there, but believe it or not people do still use and develop for those platform!
Also for companies like ourselves, switching from our Watcom based development environment to a GNU C based environment was not an option we were interested in pursuing (lack of 32-bit DOS remote debugging, totally different inline assembler and more makes it a painful switch).