7 ms·

jwz makes it clear that his deeper complaint is not about removing the cruft per se, it's about removing vast swaths of the API and then continuing to call it "

• city41 14y ago
  But it's not OpenGL. It's OpenGL ES. Windows 8 is also not Windows 95.
  • psykotic 14y ago
    > Windows 8 is also not Windows 95. Windows 8 is backwards compatible with Win32 and even Win16. If it wasn't, there would be hell to pay. WinRT is a somewhat clean break with the Win32 legacy. But that's only required for Metro apps.
    • fpgeek 14y ago
      To be fair, 64-bit Windows 7 (and Windows 8) don't support Win16 (as I understand it, because you can't sneak real-mode code into x86 64-bit mode the way you can in x86 32-bit mode). OTOH, let's be clear about what Win16 is. Win16 is an API that Microsoft deprecated in 1995 (not coincidentally, when Windows 95 was released). In other words, Microsoft took 14 years to go from deprecation to significant (partial) non-support.
      • psykotic 14y ago
        One major reason there have been 32-bit versions of all Windows releases up to and including Windows 8 is so that corporations big and small will be able to seamlessly continue running their crusty Win16 and MS-DOS legacy applications. If not for that, many companies would not have been able or willing to upgrade. Microsoft could instead have taken a DOSBox or Rosetta style approach. Hopefully they will do that with some future release, so developers will no longer have to worry about 32-bit support. So, I feel my original statement was accurate in both its letter and spirit.
        • fpgeek 14y ago
          Oh, I completely agree with the spirit of your statement. And my disagreement over the letter is over the interpretation of an unqualified "Windows 8" (or "Windows 7"), not about the substantive facts. The reason I went into that level of detail is because I wanted to highlight the insanely long 14-year deprecation cycle. Is that a record for a deprecation that was eventually removed?
          • derpmeister 14y ago
            I think if you focus on the win{16,32} API, it doesn't do any justice to, for instance, the C library. FreeBSD has always supported binaries from various UNIX systems and I think this heritage goes back a bit further then 1995. Also, windows bundles a c library of its own which implements a significant subset. Sure win{16,32} support a GUI with bells and whistles but that's because it evolved several years later specifically to support this newer mode of UI. It does not support 50-year old teletypes.
            • fpgeek 14y ago
              You misunderstand my point about length. I'm completely aware that there are plenty of APIs that have been supported far longer than Win<anything>. That's not what I'm talking about. What I'm wondering is this: Has there ever been an API with a longer deprecation period than Win16? Remember, Microsoft announced the deprecation in 1995 (IIRC), but it didn't start to bite until 64-bit Windows mattered (you could draw the line at some server versions, Vista, or, as I do, at Windows 7). No matter how you slice it, that's a long time.
              • hapless 14y ago
                X11: 1987. Still works in 2012.
                • msbarnett 14y ago
                  X11, not backwards compatible with X10 or X9. OpenGL 4.2, backwards compatible to OpenGL 1.0 (1992) OpenGL ES, not backwards compatible with OpenGL. There's an obvious parallel here of APIs being compatible within themselves but not across boundaries between major architectural revisions intended to throw out cruft and target new environments.
      • raverbashing 14y ago
        Sure, MS took 14 years to deprecate this Which it absolutely doesn't mean you should wait 14 years to stop writing for Win16! And I think that's what the rant is implying
    • briandear 14y ago
      Ok Mac OS X Lion is not System 9. And no, Lion isn't backwards compatible to System 9 and there hasn't been hell to pay.
      • Spooky23 14y ago
        The difference is that tens of thousands of business users used System 9. The Microsoft platform probably had hundreds of millions.
      • danudey 14y ago
        The actual name of the OS changed to 'MacOS' as of MacOS 8.x. The 'System X' designation ended with System 7.5, sadly.
• msbarnett 14y ago
  They didn't call it "OpenGL". They called it "OpenGL ES". The ES is a significant part of the name. The fact that the name happens in part to contain the word "OpenGL" is not a promise of source compatibility, and even the most cursory glances at the documentation would have made it clear that the API has a different name because it is a different API. It's incredibly daft to argue that part of a name amounts to a promise of backwards compatibility with a different API, in perpetuity. The X11 protocol isn't backwards compatible with that of X9 simply because they both share a name-fragment.
• bcowcher 14y ago
  So OpenGL ES (Embedded systems) was not different enough? I actually think OpenGL ES didn't go far enough in the initial spec. ES 1.1 still has alot of the old fixed function pipeline, but then in 2.0 they scrapped it all entirely, opting for a smaller, more modern API. That, to me, was a bad move. I think they should've made the shader based pipeline in 2.0 part of the 1.1 spec.
  • hermanhermitage 14y ago
    Interesting. I hear what you are saying. To contradict everything I've said elsewhere on compatibility - I'm actually in favor of the 1.0/1.1 OpenGL ES standards and would have liked WebGL to offer 1.1. My self deceiving justification in this instance is that plenty of platforms that can touch the web are still running hardware only capable of fixed function (eg. Intel 945GM). Fixed function is easy to make safe, and offers a path to leverage 3d acceleration on these platforms that cannot be beaten in software. Sure its not as exciting as 3d with programmable shaders, but it is still useful 3d none the less.
    • johntb86 14y ago
      Based on Wikipedia, the 945GM has a GMA950, which supports Pixel Shader 2.0. That should be enough for WebGL. At that point, the issue is more likely to be driver quality. Allowing people to use weird fixed-function corner cases of the OpenGL spec would make problems more likely.
    • greggman 14y ago
      Fixed function is no easier to make safe than shaders so that's a false assumption. OpenGL ES 1.1 on JavaScript would be a joke. Do you really think JavaScript is up to tens of thousands of glVertex glColor glNormal calls per model per frame? The rest of the graphics world left OpenGL 1.x long ago. OpenGL 4.0 has none of the fixed function stuff in it anymore either. Using fixed function features in 2012 is like using oldskool 80s BASIC with line numbers and no functions as your programming language. It's time to move on.
      • 14y ago
• saurik 14y ago
  Right, but again: those are the parts of the API that are already discouraged and downright deprecated as of OpenGL 2.0. If you were developing an app targeting OpenGL 2.0, following what I understand are the best practices for that version of the specification, OpenGL ES will require little to no porting. The problem then, arguably, is not that OpenGL ES is called OpenGL but that OpenGL 2.0 added an entirely unrelated pipeline to that used in OpenGL 1.3: you could then claim "how dare they reuse the name for what is now two APIs stuck into one library". However, they shared a lot of underlying conventions, and they were honest about bumping the major version number. If anything, the fact that jwz is happy he proved--that you can build an OpenGL 1.3 emulation library over OpenGL ES--would argue to me to /not/ include the 1.x features as part of the standard, but to instead encourage third parties to distribute such libraries. The fixed function pipeline wasn't removed from the API as it is unimplementable, but because it is a ton of obsolete code that 2.x coders avoid anyway.
  • fpgeek 14y ago
    OpenGL 2.0 was released in September 2004 (Wikipedia). OpenGL ES 1.1 (which jwz complains about here) was ratified and publicly released in August 2004 (going back to OpenGL ES 1.0 would only make the comparison worse, of course): http://www.khronos.org/news/press/khronos-group-announces-the-on-time-delivery-of-the-opengl-es-1.1-specifica http://www.khronos.org/news/press/khronos-group-announces-th... That's a quite, um, impressive deprecation cycle, I suppose.
    • saurik 14y ago
      Touché: I apparently wanted "OpenGL 1.5", not 2.0. This, in fact, undermines part of my argument regarding the major version number. Further, reading through the history and timeline a bit better, I am now concerned I was horribly misinformed. I would just ignore my comment.
    • prodigal_erik 14y ago
      Seven years is not a long time. My toaster is older than that, and I like to think the people who made that would be embarrassed if those cheap moving parts had decayed so quickly. You probably have enough horsepower at your disposal to emulate each and every computer you ever bought (simultaneously!) and run all that software forever. But instead we're going to require any tool you want to use to be rewritten half a dozen times over the course of your career alone. And why? Because fuck you, we just can't be bothered to start taking engineering seriously.
• deleted 14y ago
  [deleted]