So you want to formalize the use of Glk as a library in some other program? Instead of, as it really currently is, an application which can be compiled with a portable VM/game core.
Yes, exactly. Well, sort of; I don’t care if you say “this is a library now,” but it would be nice to facilitate its use as a library (without hampering its use as an application). I assume this would just give the VM more choice about how to use Glk; the library approach and the application approach should both be viable. Either implement
glk_main and compile everything together as an application, or compile Glk implementation as a library (or grab DLL from web) and call
glk_init at the top of your own
glk_quit at the bottom.
You can do that but I don’t think it needs to be in the spec.
It doesn’t need to be, but putting it in the spec would allow for interchangeability among libraries. For example, Windows-Glk distributes a DLL and exposes an
InitGlk, and if I want to commit to that Glk implementation, I can call that. But then I need a different code path for a different implementation, can’t support unknown future implementations, and the user can’t simply swap out the DLL for something else, because
InitGlk only exists in that library. If all libraries had the same interface for initialization, we could write implementation-agnostic Glk code.
I’m a little confused about last paragraph.
In your proposal, glk_init and glk_exit would be implemented by the Glk library,
glk_quit would be stuff that’s already part of Glk implementations, it’s just that it would be moved out of
glk_exit, so it can be accessible (without terminating program) when Glk implementations are compiled as libraries.
whereas glk_main is implemented by the VM.
Right, isn’t it that way already?
This isn’t consistent and it doesn’t really add anything to the spec. That is: if you’re implementing a Glk library, you can write your main() this way, but it doesn’t add any interoperability because (e.g.) the glulxe VM code doesn’t call glk_init.
Something like glulxe wouldn’t need to call
glk_init, and it calls
glk_main which would be implemented by glulxe, right?
So, it doesn’t add anything to that scenario, it stays the same… the interoperability benefits are all for the case where it’s used as a library.
On the flip side, it doesn’t go against the spec either. Except for some confusion in naming the functions glk_init and glk_quit.
Right, if it’s not in spec I’d treat
glk_* as reserved. But the point of getting it in spec would be so that
glk_init works in any Glk implementation conforming to that version of spec, so that clients of Glk libraries can be implementation-agnostic.
I feel like either the suggestion wasn’t as clear as it should have been, or I’m missing something about how it works, or misreading your reply somehow, but thanks for taking a look!
Alright, reading over this again, I think I see what you’re getting at – supporting the current approach and the library approach at the same time is inconsistent. What I’m suggesting is that client code could use one approach or the other, but not both. I’m not sure consistency is an issue here if client code is picking one approach or the other instead of mixing them somehow. In the Glk implementations, it would just be a minor change, making things that are already there a little bit more granular, mostly so that nothing exists only in
The library approach is useful for cases where Glk is being combined with something else that also defines
main, or in cases when dynamic linking is preferred. The current approach is already in use, and it’s convenient for static builds, so I don’t want to suggest replacing it, but there’s no reason it can’t coexist with the library approach (Windows-Glk is already doing this, as far as I can tell).