Embedding files within DLLs?
Author
Ok, I''ve developed a library/API and want to distribute it in DLL form. The only problem is that the DLL needs some binary files (TTF font files). And I''m trying to be platform-independent in the long run (i.e. I should be able to compile the library as a Unix .so file later).
Is there a way to embed binary files into a DLL?
What is the typical solution to this problem?
[ CodeDread ]
In Windows, a DLL, like all executable modules, may be linked with resources, including custom resources. For more information try looking up LoadResource()/FindResource().
Typically, for this problem, you would just install the font on the system, or otherwise keep it separate from the executable module.
Typically, for this problem, you would just install the font on the system, or otherwise keep it separate from the executable module.
You can embed any data in an .exe or a .dll, by adding it as a resource and accessing it as the RCDATA type.
Author
Problem here is that I''m using the SDL TTF library to load fonts (via SDL_OpenFont calls). Thus, I need to supply it as a filename. Is there any way to embed a resource within a dll/exe, then sort of extract it at runtime as a file that can be accessed via a filename? I think I might be asking too much here.
On the other hand, I''m not sure how I would go about deploying the library with the font files. The library package just comes as a folder with a lib/, include/ and docs/ folders. I don''t want to rely on some custom path for these fonts if I can avoid it (i.e. how do I "save" the path within the DLL and always ensure the files are located there?).
The other, less desirable option is to force the user to setup my library with the fonts he wants.
Any other ideas?
Thanks,
Jeff
[ CodeDread ]
On the other hand, I''m not sure how I would go about deploying the library with the font files. The library package just comes as a folder with a lib/, include/ and docs/ folders. I don''t want to rely on some custom path for these fonts if I can avoid it (i.e. how do I "save" the path within the DLL and always ensure the files are located there?).
The other, less desirable option is to force the user to setup my library with the fonts he wants.
Any other ideas?
Thanks,
Jeff
[ CodeDread ]
You could embed as a custom resource, and spew out the contents to a file you get from GetTempFileName() and pass that file to the SDL TTF library.
But I think we''re ranging a bit far afield here. What is your library doing that it needs this custom font? It could be that there''s a more elegant way to handle things here.
But I think we''re ranging a bit far afield here. What is your library doing that it needs this custom font? It could be that there''s a more elegant way to handle things here.
Author
It''s kind of tricky. The library is an implementation of Borland''s old DOS-based BGI library. I used specific fonts and specific font sizes to try and emulate the old Borland stroke fonts.
Thus having the user set the fonts manually is not a preferred solution.
[ CodeDread ]
Thus having the user set the fonts manually is not a preferred solution.
[ CodeDread ]
Oh dear god, you had to choose one of the hard ones. IIRC, the original BGI worked like this: the font files were actually renamed object files that exported the data in the form of weird global variables. I can think of a way to get a similar effect in a semi-portable manner, but it wouldn''t be pretty.
Basically, dump the font binary in a const global array in a code file. Then, because SDL TTF is a wrapper around FreeType, you can hack a mod to it so that instead of loading from a file, SDL TTF will load from the byte array, via the FreeType FT_New_Memory_Face() function. (Intead of reading from a stream like the current SDL TTF OpenFont() functions do.)
Personally, I think the temp file approach would be easier.
Basically, dump the font binary in a const global array in a code file. Then, because SDL TTF is a wrapper around FreeType, you can hack a mod to it so that instead of loading from a file, SDL TTF will load from the byte array, via the FreeType FT_New_Memory_Face() function. (Intead of reading from a stream like the current SDL TTF OpenFont() functions do.)
Personally, I think the temp file approach would be easier.
Author
Thanks for the ideas SiCrane...you''re right, it''s quite an ugly solution no matter which way I do it.
Your second approach sounds pretty portable, though it involves interfacing with FreeType and may take me longer to get right. I may go with the resource-to-temp file approach for starters (which isn''t as portable because it relies on DLLs and OpenResource or whatever).
By the way, do you know anything about the old Borland stroke fonts? I tried to find a way to convert them to TTF but didn''t come up with anything on the internet. Thus, I''m going with TTF look-alikes.
Thanks again,
Jeff
[ CodeDread ]
Your second approach sounds pretty portable, though it involves interfacing with FreeType and may take me longer to get right. I may go with the resource-to-temp file approach for starters (which isn''t as portable because it relies on DLLs and OpenResource or whatever).
By the way, do you know anything about the old Borland stroke fonts? I tried to find a way to convert them to TTF but didn''t come up with anything on the internet. Thus, I''m going with TTF look-alikes.
Thanks again,
Jeff
[ CodeDread ]
IIRC, the BGI fonts were basically just the equivalent of bitmap fonts. Short of rendering them and manually applying point information to a font builder program, (essentially the same process as building a new font from scratch) I can''t think of any way to turn them into TTF.
SDL_TTF supports the SDL_RWops system, which is not documented within SDL. However, there''s a good introduction here, and the interface to SDL_TTF is here.
IIRC, you should be able to get a pointer to the resource (LoadResource() and LockResource() at first glance, but I''m not sure) and work from there, but that''ll toss portability out the window.
IIRC, you should be able to get a pointer to the resource (LoadResource() and LockResource() at first glance, but I''m not sure) and work from there, but that''ll toss portability out the window.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement