With platform defined as the combination of operating system, video chip, and drivers OpenGL is far from being platform independent. From opengl.org:
One of the greatest strengths of OpenGL is that it was designed to be readily extensible to accomodate new hardware innovations. Using the OpenGL extension mechanism, hardware developers can differentiate their products and incorporate new features by developing [...]
I didn’t copy-paste the whole thing because this really says it all. My understanding/feeling at this point is that OpenGL is both:
  1. a standard (with several versions) and chip makers do or do not claim to implement it, and
  2. a framework, meaning a chip maker can use existing interfaces and infrastructure for making/promoting/delivering his own features
The 2 is the problem, as those features are not intended to be standardised (though sometimes they are, in a new version of the standard). So when a programmer writes something that uses an extension present on his chip, later porting that code to work on all chips is a seriously nasty business. Which of course is what I’m doing now. Oh well, if it were easy it wouldn’t be worth doing :) B. Smedberg did a huge favour to all mozilla developers with his MozillaBuildSetup-1.1.exe, which made the development setup for building Mozilla trees so much easier compared to cygwin. But now, with no disrespect, I have to say I’m sick to death of that package. At first it was the home/end/delete keys not working, and .inputrc files ignored – well whatever; then it would fail to refresh the terminal window properly, so some scraps of the old text would be left over – fine; but now the terminal appears to freeze after outputing a certain ammount of text (while make apparently keeps working in the background). So I made my own. Here are the ingredients:
  • MSYS-1.0.10.exe (from MSYS)
  • binutils-2.15.91-20040904-1.tar.gz (from MSYS)
  • gcc-core-3.4.2-20040916-1.tar.gz (from MSYS)
  • gcc-g++-3.4.2-20040916-1.tar.gz (from MSYS)
  • libiconv-1.9.1.bin.woe32.zip (from gtk-win32)
  • python-2.5.1.msi (official Python installer)
  • zip.exe (from info-zip)
  • moztools (from MozillaBuildSetup-1.1.exe)
After installing/extracting those, I edited C:\msys\1.0\msys.bat and inserted this at the top: call "C:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat" set MOZ_TOOLS=C:\msys\1.0\moztools PATH=%PATH%:/c/Python25:/c/msys/1.0/moztools/bin And now I have a fully working mozilla build environment, without the quircks and the bugs from Smedberg’s old package. Sadly this setup cannot be zipped and put online, cause I didn’t expect to be successful in making it. But maybe next time I do it I’ll make MozillaBuildSetup-1.2.exe for the world to use. Erm, hrm.. right. How am I supposed to debug canvas3d without the source code for canvas3d? Here are the contents of canvas3d.xpi: ls -R .: chrome/ chrome.manifest components/ install.rdf platform/ ./chrome: canvas3d.jar ./components: canvas3d.xpt ./platform: Darwin/ Linux/ WINNT/ ./platform/Darwin: components/ ./platform/Darwin/components: libcanvas3d.dylib* ./platform/Linux: components/ ./platform/Linux/components: libcanvas3d.so* ./platform/WINNT: components/ ./platform/WINNT/components: canvas3d.dll Unless an .xpt file is extractable like an .xpi, the extension only contains binaries: canvas3d.xpt, libcanvas3d.dylib, libcanvas3d.so, and canvas3d.dll Maybe the source code is in in lxr. I guess I should read that. This is where we will try and keep each other up to date about what we do. Maybe it will be interesting to someone outside the project, and maybe not, entertaining random folk is not the point anyway. We are Mark Paruzel and Andrew Smith, working under the supervision of Cathy Leung on the Canvas3D project started by Vladimir Vukicevic.