RE: Beta 10 Last call
- From: William Adams <william_a_adams@xxxxxxx>
- To: <luajit@xxxxxxxxxxxxx>
- Date: Mon, 7 May 2012 02:12:45 +0000
I have written some Winapi bindings. You can find my work here:
https://github.com/Wiladams Primarily it's in this repository:
https://github.com/Wiladams/BanateCoreWin32 Invariably, things move to my
HeadsUp project: https://github.com/Wiladams/HeadsUp There is a core/win32
directory in there. The stuff in HeadsUp will typically be more up to date,
as I improve it with real applications there, leaving the stuff in
BanateCoreWin32 as the initial startup effort. The way I've been approaching
things is to pull in APIs as I use them. I'm not after reproducing the
entirety of the Win32 set, because 90% of it is so specialized I'd never use
it, and I don't want to maintain such a large codebase. I had previously done
a lot of interop work in C#: https://github.com/Wiladams/NewTOAPIA So, that's
where I'm drawing most of my examples from. I am trying to isolate things in
such a way that I could provide a small number of portable os services, but my
real effort is focused on Windows itself, as that's big enough for my most
immediate needs. I have spent a fair bit of time with the OpenGL API in
particular. I've covered OpenGL, OpenCL, wglext.h, glext.h, and the stuff in
GDI so that writing OpenGL code, including interacting with shaders, is almost
mindlessly simple. The biggest effort here was coming up with a proper
forwarding mechanism for extension methods. Basically, all the signatures have
been cdef'd, and whenever you make a call, through this OglMan 'object', if it
hasn't seen the method call before, it will look for it. If it finds it, a
pointer to the function is returned, if not, you get nil. That's about as easy
as that part gets. Then, for shaders, I use a similar trick for setting/getting
uniform values. So, it's pretty straight forward to work with uniforms, they
just look like regular field accessors on a table. But, this needs more work,
and I need to deal with attributes as well. At any rate, as Mike suggested, I
could do a summary writeup on my various excursions and post here. I think one
area that could really benefit from some focus is reading of typelib
information. With that, many COM interfaces could be automatically generated.
And, you won't actually need to generate code in a file, it could just be done
at runtime. Similar for .net. Just read the metadata from the .dll, or .exe,
and construct up function calls from there, directly. Having these two pieces
in hand would greatly simplify the life of anyone trying to communicate to
these different systems. -- William
===============================
- Shaping clay is easier than digging it out of the ground.
http://blog.nanotechstyles.com
http://www.thingiverse.com/WilliamAAdams
https://github.com/Wiladams
> From: cosmin.apreutesei@xxxxxxxxx
> Date: Sun, 6 May 2012 22:26:16 +0300
> Subject: Re: Beta 10 Last call
> To: luajit@xxxxxxxxxxxxx
>
> > [I have some ideas for coordinating that sub-ecosystem, to avoid
> > everyone writing standard FFI bindings from scratch.
>
> Waddaya got? I'm interested.
>
> I'm thinking the same as I'm writting my winapi binding right now.
> Anyone doing winapi right now?
>
> [Me, first I just wanted give the ffi a go on a heavy API to see how
> much I can do without touching C. I avoided ffi until callbacks were
> implemented (I knew I couldn't do much without them - I still get a
> "bad callback" every now and then but I diverge). Anyway, two weeks
> into it and I can't stop, the API is so friendly it keeps me in the
> state of flow (as opposed to the
> find-creative-workarounds-I-feel-like-quiting-is-this-worth-my-time
> state that other APIs insist I should be in). It's still grunt work
> sure (anything with C in it is), but it's not painful, more like
> physical exercise. Seems like the technical problem has been solved.
> The opportunity to write bindings is now open to a lot more people
> (with less C mojo, people that have a life, etc.). Now we need find a
> solution to match for the social aspect.]
>
Other related posts:
