Jump to content
EduGeek EdSec 2026 is Go! 27th Oct in Derby! Join us for a day of EdTech security focused talks, networking, and an evening social ×

Recommended Posts

Posted (edited)

Normally I would consider such a statment harracy and punishable severely but recent events have swayed my viewpoint a little.

 

The universal truth seems to be that developers are lazy, preffering to do the least possible to get a system working. This is even worse in an educational environment where multiplatform means using as many abstraction layers as it takes to get the job done without writing another line of code.

 

Most of the education resource type apps here are written in flash and packaged in an executable player, this system I had thought was rather nasty as it fell back to flash of all things but TBH actually ended up working quite well, Windows and Mac support with no need to install and simple to just run off a file share. Functionally this idea is actually fine and its just my code snobbery (along with my dislike of Flash) that caused my issues with it.

 

Now one day we get a new testing app (universally lauded for its educational outcomes . . . . Danger, Danger Will Robinson) which is multiplatform but instead of running flash behind the scenes it uses python and OpenGL.

 

Yay I thought, real code in an almost respectable language and using OpenGL it must be flashy...

 

Wrong!

 

The app itself is totally unremarkable visually but does rely heavily on OpenGL acceleration to make the buttons pulse slowly in the background. Not only that but it cannot use an existing network connection context insisting on opening a new one which is fine in a domain environment but in this instance makes it unusable on certain stations (standalone with mapped drives and stored credentials).

 

 

Down to the problem, OpenGL 2.0 is not too new but is not supported over RDP, this means that this app can't run over RDP, no terminal server, no Multipoint server and all to make the buttons pulse.

 

The issues actually lie deeper within the app as I found a nice little library that runs OpenGL 2.0 in software ( Mesa Home Page ) which I compiled and which works on Server 2008 R2 (all be it slowly). Yay I thought, a way around the problem, wrong again, software that is closer to the hardware and helpfully uses unsupported calls directly to it have a nasty tendancy to kill the process meaning that this app despite its better underpinnings comes out as a total looser when it comes down to portability.

 

 

In conclusion, in some instances, OpenGL is worse than Flash for portability and usability.

 

I am still in shock.

 

EDIT: As it may be of use to someone else I have attached a ZIP with the three DLLs to this post. The idea is to just drop them in the same folder as the EXE of the unhappy program and it will override the windows OpenGL libraries for this program.

 

Turned out to be helpful here where the new intel chips/drivers did not support OpenGL properly or in a way that some older software could detect.

GLU32.zip

Edited by SYNACK

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...