3 ms·

I did appreciate that Microsoft gave reasons along with their snub, but their analysis felt pretty NIH-and-not-going-to-help-with-the-inventing to me. Shaver s

I did appreciate that Microsoft gave reasons along with their snub, but their analysis felt pretty NIH-and-not-going-to-help-with-the-inventing to me. Shaver says: >I also suspect that whatever hardening they applied to the >low-level D3D API wrapped by Silverlight 3D can be applied >to a Microsoft WebGL implementation as well. Nice point. Whether Microsoft engages with and helps improve WebGL could be seen as a proxy for whether they will in fact engage with Web Standards in IE 1X. Or is WebGL so broken that it's impossible to contribute? I'm also surprised since the next battleground for browsers seems to be in mobile and pushing forward a unified and seriously advanced browser strategy could be a serious advantage for MSMobile (whatever the hell it's called now). Instead, they seem to be re-fighting battles in a war that's already been semi-lost (the PC browser).

kenjackson 15y ago
One thing to keep in mind though is that while MS is one company I don't think the IE team and the Silverlight team see eye-to-eye on everything. It could well be the case that the IE team thinks that what SL does is something they wouldn't put into Windows.
- shaver 15y ago
  The post wasn't from the IE team, but from MSRC, the company-wide security research group.
  - kenjackson 15y ago
    I missed that, thanks. In that case they pretty clearly know the delta between the XNA in SL support and OpenGL. Do you know what the big differences are in how shaders are handled between XNA and OpenGl? Can we work to get them to be more similar?
    - shaver 15y ago
      The shader models in XNA D3D and WebGL are pretty similar. One travels as pre-compiled bytecode and the other as text, and there are some differences in how loop constructs work, but they're both basically shader model 2. But the argument I read from MSRC wasn't about the capabilities of the system when working as intended, it was about weaknesses in OEM/IHV drivers causing unintended behaviour that is qualitatively harder to fix than bugs in the drivers for hardware H.264 decoding. I haven't yet found a way that HLSL/XNA is more robust than GLSL/WebGL, and I've been in threads about those shader models for quite a while now. Of note, perhaps, is that on Windows we compile GLSL into HLSL and then effect bytecode (with Microsoft's compiler) and feed it through Direct3D. It's a very very similar pipeline. The claim is that driver blacklisting hasn't been used to address recent vulnerabilities, but...the recent vulnerabilities have had nothing whatsoever to do with problems in a driver.

kenjackson 15y ago

One thing to keep in mind though is that while MS is one company I don't think the IE team and the Silverlight team see eye-to-eye on everything. It could well be the case that the IE team thinks that what SL does is something they wouldn't put into Windows.

shaver 15y ago
The post wasn't from the IE team, but from MSRC, the company-wide security research group.
- kenjackson 15y ago
  I missed that, thanks. In that case they pretty clearly know the delta between the XNA in SL support and OpenGL. Do you know what the big differences are in how shaders are handled between XNA and OpenGl? Can we work to get them to be more similar?
  - shaver 15y ago
    The shader models in XNA D3D and WebGL are pretty similar. One travels as pre-compiled bytecode and the other as text, and there are some differences in how loop constructs work, but they're both basically shader model 2. But the argument I read from MSRC wasn't about the capabilities of the system when working as intended, it was about weaknesses in OEM/IHV drivers causing unintended behaviour that is qualitatively harder to fix than bugs in the drivers for hardware H.264 decoding. I haven't yet found a way that HLSL/XNA is more robust than GLSL/WebGL, and I've been in threads about those shader models for quite a while now. Of note, perhaps, is that on Windows we compile GLSL into HLSL and then effect bytecode (with Microsoft's compiler) and feed it through Direct3D. It's a very very similar pipeline. The claim is that driver blacklisting hasn't been used to address recent vulnerabilities, but...the recent vulnerabilities have had nothing whatsoever to do with problems in a driver.