Windows functionality Pull request for discussion.

[jgleesawn]

Synopsis: -First two commits were base changes for binding generation and the type mapping. -Third commit was fixing everything I broke in the first two commits. -Fourth commit was removing debug messages and changing the @opengl_lib default value.

I'm not saying this should be pulled as is, I'm not pleased that I changed the structure of fiddle-symbol-loader.rb but Hash's default_proc being a block/proc I couldn't call Fiddle::CParser::parse_ctype from within it due to context/scoping issues.

Windows is restricted to opengl 1.1 functionality if you are calling functions solely from opengl32.dll. This change essentailly bakes in wglGetProcAddress lookups for functions that aren't found in opengl32.dll I did throw it in a switch though so aglGetProcAddress lookups are automatic on Macs and glXGetProcAddress lookups are automatic on Linux machines. These are not tested though and I don't know that any agl calls are listed in the opengl spec xmls I extended it to use as well.

Anyways, thanks for doing all the work to get it to the state that its currently in. If you think its fine I'm fine if you accept the pull request as is, I just didn't want you to feel obligated haha.

[nilium]

I'll look over it on the weekend. Don't really have any thoughts one way or the other 'til then. Only problem will be that I don't run Windows on anything, so about all I can do is ensure it works on OS X and assume Linux still works.

[jgleesawn]

I've been trying to do some more with it, for some reason GL_INVALID_OPERATION errors are continuously being generated. ~~So at this point I would call it semi-functional under windows.~~

It seems to have issues with the opengl32.dll I grabbed from C:/Windows/System32, but using the opengl32.dll wrapper from here: http://people.freedesktop.org/~jrfonseca/apitrace/apitrace-mingw-latest.7z All glErrors are now gone. This may or may not come with a performance hit. I do not know what the dll entails that is different from the original.

Note for posterity, this is all under msys2, not in a native windows environment.

[nilium]

Looking it over for a bit, I think there's a better way to get the FiddleSymbolLoader to use parse_ctype (didn't know that existed, so that's handy). I'd prefer not to include or extend using any component of Fiddle, just because Fiddle's kind of a mess.

I think I can probably merge in the changes to gen_from_xml.rb sooner rather than later since that's all harmless and it'd be good to have it. I don't really see anything wrong with that — everything awful about the script, which is most of it, is my fault, so I'm glad getting it working for wgl and glx only required a few changes.

Not entirely sure what the @type_alias ivar is doing there (line 21 of the symbol loader) — the point of TYPE_MAPPINGS is that, beyond some initial writes, it would be a mostly-read-only cache of common types in for the GL bindings. Less purposefully, it's just a map of known type names to their fundamental types (i.e., anything that isn't a pointer). There shouldn't be any specific reason parse_ctype couldn't be used within the default_proc of TYPE_MAPPINGS as such.

The most obvious issue is that, right now, merging this would completely break Mac OS and Linux support just because it unconditionally attempts to load opengl32.dll (line 90) regardless of platform or anything else, which obviously won't work (load_sym handles shared object loading, so initialize should do close to nothing other than set a couple ivars).

So, there's more work to be done on this and I'll have to look into some of it. Go ahead and leave the pull request open and keep working on it if you've got time, since I know less about WGL these days than I did ~7 years ago and it'll help me work out what we need to get working. The only downside is that I'll be busy for the next few days and then traveling for about a week, so I'll only really have a little bit of time this Thursday and probably next Monday or Tuesday to look at anything else.

Either way, the help's appreciated, since I'm just not in a position to do the Windows side of things. Thanks.

PS: I also have no idea what that other opengl32.dll is. Would be better to avoid it since if opengl-core doesn't work with baseline Windows, it's mostly guaranteed to be an issue with opengl-core and not the DLL.

[jgleesawn]

Thanks for taking a look. The @type_alias is just what you said, Fiddle's TYPE_MAPPING and its there because I was trying to shoehorn Fiddle::Win32Types in, it could easily be statically typed instead. There is some funky context switching that takes place in blocks procs and lambdas that prevent parse_ctype from being called from within. This is about where my searching took me when trying to come up with a solution: http://stackoverflow.com/questions/2381927/including-methods-into-blocks

The init is understandable, I put that in the commit because it was the lowest scope way I could actually get it running on my system without tweaking parameters, I'm not sure why it won't load functions if loaded normally. Opengl32.dll: I agree its a terrible solution, just figured I'd toss the information out there if anyone is trying to have at it while there isn't a proper solution. Given, the problems I'm having could be solely on my system.

I'll probably try to spend some more time on these over the next period of time. Enjoy your travels and thanks for your time.