Did anybody else notice this job listing?
http://www.opengl.org/classifieds/offered/jobs/Detailed/80.html
Note in particular the contact email address at the end, and the words “next generation”. Could they actually be planning to - gasp - update opengl32.dll?
Don’t understand the bit about working on hardware drivers though. How is this Microsoft’s job? XBox, maybe?
I noticed it.
Microsoft wears many hats,it is on the ARB, needs OpenGL for workstation class graphics (this has always been their position) etc.
I don’t think you should read too much into this.
[This message has been edited by dorbie (edited 02-24-2003).]
They’ve also, recently I think, updated their documentation on MSDN to eliminate some of the errors that have been their since day dot.
I fail to see how Microsoft could get by without aggressively making sure they’re the best-performing OpenGL platform on the market. Workstation people would be just too glad to have an excuse to go to Linux instead.
Microsoft needs to make sure OpenGL runs best on Windows, for Microsofts own interests. Whether they understand this, I have no idea 
Since D3D started Microsoft has been caught between the need to support OpenGL and be competitive and the need to crush OpenGL with their proprietary API and be anti-competitive. I’m sure both sides of the issue have been clear to them since the beginning.
Originally posted by jwatte:
Microsoft needs to make sure OpenGL runs best on Windows, for Microsofts own interests. Whether they understand this, I have no idea
No they don’t. The ball is in the individual hardware vendors hands and they have to make sure their graphics card is the stablest fastest one of all. They (I mean MS) need consultants, who will be helping other companies.
The number of job offers involving game development + medical, military, scientific needing some GL graphics compared to driver writers for GL seem to be equal. Very odd.
[This message has been edited by V-man (edited 02-24-2003).]
Microsoft does have some measure of responsibility for OpenGL under Windows. The reason that Win32 GL programmers have to upload extensions for Gl 1.2-1.4 manually is because Microsoft has not updated OpenGL32.lib. That is their library that serves as a go-between for the user and the driver.
The question as to how Win32 programmers will access GL2.0 has been around since 2.0 was announced. There were rumors that the ARB itself might take over OpenGL32.lib, or write a new interface library. But now, it appears that Microsoft may be willing to play ball and write it themselves.
This is a good sign for the future of GL.
If they did write it themselves it would be a change of heart on a, ehem, rather large scale.
I’m guessing jwatte is closer to the truth. Not supporting GL fully is probably hurting MS now in the “serious” workstation market, rather than benefiting D3D. D3D is still an excellent product though, don’t get me wrong.
I was going to say actually, that if this is true, then thats excellent news for me at work!
[This message has been edited by Robbo (edited 02-25-2003).]
Say MS did upgrade their opengl32.lib/dll to 1.4 - what would happen if a card was installed that only supported, say, 1.2? Would the 1.4 exported functions be null?
Dont they have to implement all the 1.4 features via software? so that if the card doesn’t support a particular feature it falls back to the M$ generic device.
Actually, provided the driver is a full ICD and not some old Vodoo mini client driver, it’s the drivers job to provide a software fallback, noy Microsofts. If you can’t get a hardware pixelformat then you get MS’ sw implementation.
So unless the card supports 1.4, you won’t get a hardware pixel format?
Originally posted by knackered:
So unless the card supports 1.4, you won’t get a hardware pixel format?
No I don’t think the pixel format is tied to the GL version.
In some sense, GL doesn’t have version numbers, just added extensions on top of a base.
So howcome none of you are trying to hack the dll?
Originally posted by V-man:
In some sense, GL doesn’t have version numbers, just added extensions on top of a base.
Not really. GL functions are exposed by the normal dllexport mechanism, and can be statically linked against or retrieved dynamically with GetProcAddress(). GL extensions can ONLY be retrieved dynamically via the GL extension mechanism; GetProcAddress() won’t work, or at least won’t portably work.
I don’t think you can treat the two as interchangeable.
No knackered, but the driver won’t deal with certain pixel formats (16 bit color and stencil on older cards for example, or accum. buffres) which might give yoiu the MS software renderer. This is exactly the way things work now, if your card doesn’t support colour logic ops, edge flag arrays or two sided lighting in hardware, you don’t get MS’ implementation you just get those particular functions performed in software.
MikeC,
I’m not saying that the cases are interchangeable with the current situation.
GetProcAddress should always return NULL for extensions. Who has succeeded in getting valid pointers?
But if MS creates a 1.4 DLL (and maybe they need to make changes to the ICD mechanism), a driver that implements an older GL version might work.
So maybe some changes will be necessary.
Originally posted by V-man:
So howcome none of you are trying to hack the dll?
What, reverse engineer that .dll, then have a army of lawyers waving the DMCA at you? No thanks. 
Well, considering that MS resigned from the ARB last month, I think you guys are barking up a tree that’s been dead a long time.
Not much use in speculating about the job postings. You could always apply and find out!
FUNK!
Originally posted by Funk_dat:
Well, considering that MS resigned from the ARB last month,
Huh? Where was that announced?
I just did a quick Google search for any news regarding Microsoft resigning from the ARB. There was none. I would imagine that it would have, at the very least, made the front page of OpenGL.org.
