Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Open Watcom 1.0 Released

Posted by michael on Sat Feb 08, 2003 02:46 PM
from the competition-is-good dept.
Programming IT Technology
JoshRendlesham writes "The Open Watcom C/C++ and FORTRAN 1.0 compilers have been officially released. The source, and binaries for Win32 and OS/2 systems, are available. This release also means that outside developers can join and contribute to the project." Or if you prefer, gcc is up to 3.2.2.
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Open Watcom 1.0 Released 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Rise of the Triads (Score:3, Interesting)

    by Anonymous Coward on Saturday February 08 2003, @02:48PM (#5259985)
    Does this mean that I can finally use the ROTT-source for something else than just looking at? :-)

  • DOS days (Score:4, Interesting)

    by Graspee_Leemoor (302316) on Saturday February 08 2003, @02:51PM (#5260001) Homepage Journal
    Back in the days of DOS, if you were a developer, the Watcom C compiler was *the* thing to pirate.

    graspee

    • Re:DOS days (Score:5, Informative)

      by ctr2sprt (574731) on Saturday February 08 2003, @03:19PM (#5260130)
      Wasn't it the first mainstream compiler to include a complete DOS extender and feature full 32-bit support? I remember wanting it so badly in the DOS days, but I was a broke student and could barely afford the modem I used to download porn. I had to make do with Borland C++ (which was great, but lacked 32-bit support unless you felt like writing a lot of assembler).

      Anyway, I'm excited by this because, well, competition is almost always a good thing. Hopefully gcc and Watcom can feed off each other and both products will improve. And perhaps more importantly for the build-everything users, another open source compiler might start moving people (like the developers of autoconf) to better support non-gcc compilers. This way, users who prefer Watcom's (or Intel's, or...) compiler can use it without as much tweaking.

      • Re:DOS days (Score:5, Informative)

        by Graspee_Leemoor (302316) on Saturday February 08 2003, @03:21PM (#5260144) Homepage Journal
        The version of gcc for dos: DJGPP had a DOS extender and 32-bit support but it was slower than Watcom by a large amount.

        graspee

        • Not to mention that DJGPP is responsible for the worldwide shortage of sacrificial chickens and goats!! Installing it has been described as a black art, and getting good performance from the resulting binaries.. lordy. Talk about bad juju.

          (And will someone PLEASE fix the stack overflow/memory leak in CWSDPMI?? It's been there since the Go32v2 days!!)

        • >>The version of gcc for dos: DJGPP had a DOS extender and 32-bit support but it was slower than Watcom by a large amount

          Though that didn't stop ID software from using DJGPP to build Quake 1 way back in 96.

    • First of all, for the uninitiated, if your program shipped with dos4gw.exe (as most games did), it was compiled in Watcom. Such was the performance difference that nobody really bothered with any other compiler, especially with games.

      Back in the days of DOS, if you were a developer, the Watcom C compiler was *the* thing to pirate.

      I remeber using a stripped-down copy which was missing a good part of the standard C++ libraries and still doing most of my development on it. Having gotten used to such luxuries as the IDE Borland C++ (and Turbo Pascal) shipped with, it took a while to get used to but produced superb code.

        • Re:DOS days (Score:5, Informative)

          by ma++i+ude (580592) on Saturday February 08 2003, @04:25PM (#5260429) Homepage
          What exactly did dos4gw.exe do, incidently? I always used to wonder.
          It allowed the programmer to use all of the available memory. Remember when you had problems getting programs running because there was not enough conventional memory (ie. the first 640KB)? Well, dos/4gw made is easy to write programs free of these memory limitations. More information at http://www.tenberry.com/dos4g/ [tenberry.com]
          • More specifically, it "EXTENDED DOS" to the 32 bit flat address model. The problem was that the entire DOS API was 16 bit, and assumed that everything happened in the first 640K. So if you wanted to use the DOS services with your data that was not in the first 640K, you needed a translation layer -- this is what the DOS Extender (typically via an API called "DPMI" -- DOS Protected Mode Interface) provides.

            Some of the better DOS Extenders had a built-in virtual memory mechanism as well. Actually it turned out that DOS4GW was kind of weak in comparison to the other extenders like "CauseWay" which Open Watcom is supposed to be using now.
            • More specifically, it "EXTENDED DOS" to the 32 bit flat address model. The problem was that the entire DOS API was 16 bit, and assumed that everything happened in the first 640K. So if you wanted to use the DOS services with your data that was not in the first 640K, you needed a translation layer -- this is what the DOS Extender (typically via an API called "DPMI" -- DOS Protected Mode Interface) provides.

              You can run 32 bit code in dos without the restrictions and performance penalty of DPMI. It's called Flat Real mode, and has been around since 1988. Himem and Smartdrv use it to access extended memory.

              But you don't have to go through Himem to access memory above 1 meg. You can do it yourself and eliminate the time wasted.

              The problem is debugging your code to ensure data is transferred correctly. DOS debuggers cannot recognize 32-bit addresses, so you cannot verify data is stored correctly or that you are pointing to the correct area in memory.

              Here's the solution

              http://www3.sympatico.ca/add.automation/flat/frm.h tm [sympatico.ca]

              Best Regards,

              Mike Monett

      • Re:DOS days (Score:3, Funny)

        by Anonymous Coward
        Me too. I had to rob several convenience stores to save enough too buy the software, because I didn't want to pirate it.
      • No it doesn't. Your favorite distro might, but last I checked the Linux kernel does not come with a compiler, maybe you're talking about Emacs?

  • cool ! that's great news (Score:3, Interesting)

    by jacquesm (154384) <.j. .at. .ww.com.> on Saturday February 08 2003, @02:53PM (#5260008) Homepage
    I used the watcom tools extensively on QNX and they were of excellent quality, this is really good news !

    Hopefully this sets a trend.

    • Re:cool ! that's great news (Score:5, Interesting)

      by Animats (122034) on Saturday February 08 2003, @03:07PM (#5260089) Homepage
      QNX uses the GNU/GCC toolchain now, and ship their premium product with the Dinkumware C++ library.

      Incidentally, if someone can tell me how to prevent loader crashes in "ld" under QNX when there's an undefined symbol in a trivial program that includes "", I'd appreciate it. Nobody in the QNX newsgroups seems to know.

  • Watcom was great. How about today? (Score:5, Interesting)

    by CresentCityRon (2570) on Saturday February 08 2003, @03:03PM (#5260060)
    In the late 80s (?) Watcom products were really great. They were beating on everything for the Intel platform.

    I received the email yesterday about Watcom's "release" to open source. In that email it says that Sybase felt there was no commercial value in the product anymore so they released it. My question is "Has Sybase been keeping this thing up? Is it useful today?" Or is this a scam to try to give life to a dying patient? I mean perhaps people working on this might be better off working on gcc or something.

    Thanks!

    • Re:Watcom was great. How about today? (Score:5, Interesting)

      by robbyjo (315601) on Saturday February 08 2003, @05:42PM (#5260741) Homepage Journal

      One thing I know is that their optimization routine rocks.

      Well, optimization routines can be divided into two parts: One is architecture independent (which involves simplification of AST and stuff) and the other is architecture independent. IIRC, their architecture-independent optimization was really great. It can correctly detect redundant codes and simplify it.

      I used to be an ASM programmer as I was a performance freak. When I compile my C/C++ program using Watcom, it almost always produced near optimized (i.e. the "gold-standard") asm code. I knew this when I dumped out the assembler code.

      I knew that their arch-independent optimization is really good because when you add things such as calculation of busy expression (i.e. expression that you used over and over) and stuff, it correctly cache the calculation before hand. So, you will save a tremendous time, especially if you do it in a loop. The problem was (again, IIRC) that was not perfect and some of the expressions are left undetected. But, that's probably a bug.

      IMHO, arch-independent optimization play a lot greater role than the arch-dependent one (ok, some of you may not agree with me). Things like peephole optimization is great, but is of limited usefulness once you apply the correct transformation of the AST and other internal structures.

      This is also partly why Intel optimizing compiler is also great. I heard that some of the folks are doing partial evaluation on the code -- which can greatly help speeding up the result. The idea was: If you use a particular routine (like function) only with a handful of value range, it will automatically create a specialized and optimized function for you exploiting the nature of the input values. For example: You probably have seen the routine that calculates (-1)^n used in a routine that calculates x^y. The optimizing compiler thus should be able to generate: return (n && 1 == 0) ? 1 : -1; instead of the looping. This only involves some (expensive) static analyses computations. I have yet to see this in other compilers.

      Therefore, this release is really really good thing. I hope that GNU compiler teams would pickup some of their good stuff.

      • Or is this a scam to try to give life to a dying patient?
      No, it is not a scam. Sybase truly does not care what happens to WATCOM C/C++ (so long as it doesn't come back and bite them on the butt.)

  • GCC performance and another thing... (Score:3, Interesting)

    by 00_NOP (559413) on Saturday February 08 2003, @03:03PM (#5260068)
    1. GCC: My sense is that it is not a very high performance compiler - is that true? Would a better GCC make a big difference to the free software/oss world?

    2. Does the Watcom WIN32 binary run under WINE?
    • "1. GCC: My sense is that it is not a very high performance compiler - is that true? Would a better GCC make a big difference to the free software/oss world?"

      That depends on what you mean by "high performance".
      If you mean how fast GCC can compile stuff, then it's probably not the fastest compiler in this world. Hopefully precompiled headers support will change this.
      But if you mean code speed, then GCC 3.2 is great. It generates code that rivals that of Intel C++.

  • Performance comparisons (Score:5, Interesting)

    by golrien (528571) on Saturday February 08 2003, @03:14PM (#5260114) Homepage
    I was going to ask if there were any performance comparisons around showing how Watcom performed, but then I realised that anyone with half a brain ran something through Google before Slashdot.

    Win32 compilers (not including Watcom - and with good reason, it's a bitch to set up on Win32) [willus.com]

    as linked from the djgpp FAQ, some info on DOS compilers [geocities.com].

    So, hooray! A lesson in using Google before Slashdot mixed with some blatant karma-whoring.

    PS. this [bagley.org] is good too.

  • No Time (Score:4, Funny)

    by Anonymous Coward on Saturday February 08 2003, @03:15PM (#5260116)
    Sorry, no time to read this now. Will catch it on the repost....

  • Who is using Watcom in production? (Score:3, Interesting)

    by Anonymous Coward on Saturday February 08 2003, @03:18PM (#5260125)
    Could someone post information on what companies are using Watcom and which products they've built with it?

    This would also be excellent information for Watcom to put on their site. It would give them much more legitimacy.

  • GCC (Score:5, Informative)

    by mark_space2001 (570644) on Saturday February 08 2003, @03:35PM (#5260195)
    I'm with michael on this one. There are a lot of free compilers out there now, including Microsoft VC++ [microsoft.com] and Borland [inprise.com]

    Gcc is good, open, and could use some work, so please think about helping out. My favorite is MinGW [mingw.org] which is a really nice and decently maintained Win32 version of gcc and binutils. MinGW also distributes MSYS [mingw.org] which is a bash shell and other gnu utilities that make a windows box capable of running a Linux configure script. This allows much easier porting of GNU applications to windows and vice versa. There are several GUI compilers based on MinGW too, see the web page FAQ. A nice GUI GCC based compiler for Win32 is Bloodshed Dev-C++ [bloodshed.net], which I've used.

    Cygwin [cygwin.com] is good too but I prefer MinGW (obviously).

    So think about helping out, our tools will only get better if folks work on them.

      • Re:GCC (Score:3, Informative)

        by The Bungi (221687)
        Yes. It includes the C#, VB.NET and JScript.NET compilers, as well as the C and C++ compilers, along with the up to date libs and headers.

        This is surprising (was to me), because although the MS linker had been available previously with the Platform SDK, the compiler itself had never been (the libs and headers were).

        The .NET compilers have to be present in any .NET-based environment, so they have no choice but to ship them. But the C++ compiler does not. I'm not sure why they're doing this now, but hey.

        In fact, there are a couple of projects now trying to get together a free front end/IDE for the compiler, although I'm not sure if that violates their EULA. There are free/open front ends for C# (SharpDevelop and WebMatrix) available today, of course.

  • Watcom Memories (Score:3, Insightful)

    by Lucas Membrane (524640) on Saturday February 08 2003, @03:44PM (#5260238)
    The IDE's that Watcom had were refreshingly different. Their C++ IDE was good, but when they upgraded the C++, they came out with Power++, which was a very nice RAD product, but it was too buggy. If the compilers are cleaned up and they open source the IDE's too, this might be of value.

    What killed them? Did they pull all their brains off C++ to work on PB? Was competition from MS too tough? Was their GUI builder (licensed from some 3rd party) too lame? Was the cost of implementing the C++ standard too high? (Watcom was late to offer STL -- they included their own (way different) libs instead.)

    We were a couple of generations back on chips when Watcom pretty much stopped pushing their compiler technologies. I wonder how much they lose by not having optimizations targetting new hardware features.

    • Re:Watcom Memories (Score:5, Informative)

      by Locutus (9039) on Saturday February 08 2003, @04:28PM (#5260437)
      What killed them? If you remember when this all was happening, Microsoft was out to take over C++ and all the companies who did cross-platform frameworks were attached in standard MS style. Monopoly money funded subsidizing of their Visual C-- product and MS-MFC. Then when Watcom wanted to include MFC with the Watcom C++ compiler package, Microsoft said that would only happen if ALL other frameworks on the CD were removed. Remember, Watcom C++ shipped with DOS16, DOS32, Win16, Win32c, Win32, OS/2-16, OS/2-32 compilers with the IBM OCL framework and some others like Zinc if I remember correctly.

      Watcom would have to eliminate all the support for the other platforms to license MFC and ship it with their compilers. And Microsoft was all but giving Visual C-- away at the time also.

      The Watcom compiler was one of the fastest on the market from what I remember. I had heard that IBM used it for the WinOS/2 subsystem on OS/2 to make it a faster Windows than Dos/Windows.

      Think about it, Microsoft HATES anything that abstracts the Win32 API and crossplatform frameworks and crossplatform compilers where one of the early targets of the beast in Redmond. Borland was the only one that got any money out of taking Microsoft to court for attacking it's business using illegal means. The others were too small and just folded and looked for other ways to make a business.

      LoB

  • Cross compiler for PIC microcontrollers? (Score:3, Interesting)

    by EMIce (30092) on Saturday February 08 2003, @03:58PM (#5260305) Homepage
    I have been told that gcc made assumptions about processors in its design that preclude it from being made to compile for the PIC line of microcontrollers. These are great inexpensive chips that are used commercially and very accessible to hobbyists, with many "el-cheapo" programmer designs that can be hacked together with a few Radio Shack parts. They are a great way to get into the hobby, with plenty leeway to build the simplest to advanced projects, but I haven't yet found a free C compiler that targets PICs. Any idea if this new compiler will support the PIC's odd architecture?
    • PIC microcontrollers only have one general purpose register. The limitation with GCC is that it probably assumes a minimum of a certain number of registers.
    • The PIC can only store 8 return addresses on its stack, and it can only store return addresses--you can't use the stack for saving register values, for instance. This basically rules out almost all high level languages, usless they want to muck around with simulating a stack through some slow and tedious process.

      I believe there are some limited HLL's designed specifically for the PIC's limitations. However, I think the best course of action is to use a decent macro assembler. PIC assembler is easy enough to learn that it shouldn't be an obstacle for any project that could reasonably be implemented on its meager architecture.

      Oh, by the way, Atmel AVRs are the fashion this decade. No self-respecting nerd is using PICs unless they are stuck in the '90s.

  • The more compilers the better. (Score:3, Interesting)

    by Anonymous Coward on Saturday February 08 2003, @04:51PM (#5260535)
    Borland's C++ compiler pumps out some fairly slow code, but it's really good at catching mistakes the others will tolerate. Some of the problems it flags are technically legal by the standards but indicative of brain farts. Even if you throw away the binaries, it's a nice tool for weeding out slop.

    VC++ is okay, beware that the cheap/free edition leaves out the optimizations. The standard library is much improved in the 7.0 release, but MS still like to disable some default warnings to paper over their own historical sins to keep things like MFC happy. The IDE is pretty nice and the documentation for the standard library is usually damn good, but I will never forgive Visual Studio's authors for the way they chose to dedent the case clauses in switch blocks.

    g++ is finally a nice compiler in its 3.x incarnation. In the 2.9x days it was utter trash. The generated code is good and usually quite fast, but a bit on the bloated side. It is a little more permissive than I'd like even with -Wall -pedantic, but that's okay since it's not the only compiler out there. This is a good choice for producing final executables.

    The verdict is still out on Watcom. Bundling STLport already puts it a step ahead of most, that thing can be a bitch and a half to get working with some of the commercial compilers.

  • Long File Names Support (Score:5, Interesting)

    by Anonymous Coward on Saturday February 08 2003, @05:16PM (#5260633)
    I downloaded and installed RC2 last week and it went into the C:\Program Files\watcom\ directory. By default, it wanted to install to the C:\watcom\ directory.. with good reason.

    The long file name support is broken everywhere in this new release of Watcom C/C++/Fortran77. Even the included IDE doesn't do long file names. So you can imagine my disappointment when I opened C:\Program Files\watcom\\hello.c and hello.cpp in the IDE, only to get a blank file named "C:\program".

    This is 2003 and Windows 95 didn't just come out last month. I mean, Sybase told us on June 30, 1999 that v11.0 would be the last major release of Watcom C, and long file names worked just fine there. Reincarnated as open source now without LFN support, does this mean that this feature got left behind in the afterlife?

    • Re:Free software not a dumping ground! (Score:5, Informative)

      by edwdig (47888) on Saturday February 08 2003, @03:42PM (#5260228) Homepage
      The Watcom compiler is the only compiler that supports writing 32 bit code using 48 bit pointers. GCC only supports code where all the segment registers contain the same value.

    • Sure it is (Score:5, Insightful)

      by Planesdragon (210349) <slashdot@castCOL ... s minus caffeine> on Saturday February 08 2003, @03:54PM (#5260284) Homepage Journal
      Yet another company trying to use free software as a dumping ground for useless software.

      Maybe you're not up to snuff on the philosiphy of code-reuse and what Free Software means.

      If software and code is a commodity, and the value then becomes it configuration/customization, then every little bit of trash that can be opened is a Very Good Thing. If the company was proprietary their entire corporate life, but releases the soruce as GPL (or BSD) when they fold, this is a Good Act and should be Lauded and Welcomed and Thanked.

      The darn site's /.'ed--but as long as they use a GPL-compatbile license, there's nothing stopping the GCC folks from pouring over OpenWalcom for anything useful.
      • I do not see anything they can offer.
      They offer:
      1. An integrated IDE
      2. Source compatibility with MS VC++
      3. OBJ/Library compatibility with MS VC++ and MASM/TASM/NASM
      4. Compatibility with numerous DOS extenders
      5. A far better "MAKE" than gnumake, Solaris make, or MS's nmake
      6. Open source Win32 compatibility
      7. Inline assembler that uses the proper IA-32 syntax
      I am told, that the sources for the compiler itself are very well structured. I am also told that the sources for gcc are a complete mess.
      • Even if they had, would it not be better to just release the source code under the GNU GPL and integrate any valuable part into gcc?
      The Sybase Open source license protects Sybase. While that's not important to you, it *is* important to Sybase. The open source people have endorsed it as a valid open source license, so that is that.
      • Perhaps some years ago this would have been great. Now it is too little, too late.
      Now on this point you might be correct. However, that remains to be seen.
    • You complain when you don't have participation and when companies refuse to release their products under the OSS model, and then you complain when someone releases software that, in your view, is useless.

      So which is it?

    • Yet another company trying to use free software as a dumping ground for useless software. What does Watcom have to offer today?

      Let's see... a student of compilers picks it up, and learns something. The intangible goodwill encourages another company to open something else. We don't lose another piece of computer history.

      Not every act has to change the world, you know.

    • Re:Superb! (Score:5, Informative)

      by grub (11606) <slashdot@grub.net> on Saturday February 08 2003, @03:44PM (#5260240) Homepage Journal
      Don't laugh, Fortran is still widely used in the scientific field. Optimizing compilers such as the SGI/MIPS compilers do good jobs at generating tight code from Fortran. C and C++ are not the easiest things to optimize automagically.

      It's no coincidence that SGI and Cray have excellent Fortran compilers, their customers demand it.

      (sorry I spent all of last Wednesday in 2 seminars with a fellow from SGI's Canadian HPC group, I'm still buzzing. :))

    • Re:WX-REXX (Score:3, Interesting)

      by Locutus (9039)
      Same here and when I saw what VisualBasic was compared to VX-Rexx, I couldn't figure out why Watcom didn't bring VX-Rexx to the Windows platform.

      VX-Rexx was great at quick and dirty applications and prototyping. I remember writing a simple text browser in VX-Rexx when I was building a Java web server. The browser let me write html and push it to the server for testing of the parsing engine.

      If you've not seen it, think of it as VisualBasic on steroids. Hey, it used Rexx for one thing and the function browser was pretty cool for it's day. IMHO.

      LoB

    • What happened to Watcom (Score:5, Informative)

      by Anonymous Coward on Saturday February 08 2003, @04:23PM (#5260422)
      Just wondering what they(watcom) are up to now.

      IIRC: Watcom was purchased by Powersoft. Powersoft's main product was a front-end database tool called PowerBuilder. One of Watcom's products was a small database called Watcom SQL. Powersoft bought Watcom so that they could ship Watcom SQL along with Powerbuilder, so that Powerbuilder could run OOTB.

      Oddly enough, Sybase bought Powersoft a few years later so that they could use Powerbuilder to compete against Oracle's front-end tools. This meant Sybase ended up with Watcom's assets, even though they were not particularly interested in them.

    • No, actually (Score:5, Interesting)

      by exp(pi*sqrt(163)) (613870) on Saturday February 08 2003, @04:44PM (#5260500) Journal
      Intel have a long history of claiming that they produce a fast compiler, after all they know the Intel specs. However I have never found this to be true over the last 7 or 8 years (I think it was called Proton years ago). I am not sure I have found any code that is significantly faster compiled with the Intel compiler and have found much that is slower. I haven't tried v6 of their compiler though. Maybe, just maybe, they've now picked up some tricks from the KAI guys.

      Incidentally, vectorization in Intel C/C++ is a joke. I put so many hints into my code (aligned variables, processed stuff in suitable sized chunks etc.) and still couldn't trigger the compiler to vectorize. It's much easier to insert SSE instructions yourself.

      The Intel compiler has better error reporting than MSVC++. I use it when I don't understand why MSVC++ is barfing on my template code. This is more useful than it sounds!

      • Most people who have looked into this have not found your claim to be true. The Intel compiler *does* produce better code on average. I will agree with you about the code vectorization of the Intel compiler except for the very latest version of it which has actually shown itself to vectorize pretty much any time there is a reasonable opportunity for it.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.