0

I have a C library which uses a set of binary data files (read only). One of these files, lets call it f1.dat, is used in 99% of applications which use the library, while the other 59 files f2.dat .. f60.dat are used only rarely. I would like to compile the data of f1.dat directly into the library. The users of the library who never wish to use the data in files f2.dat .. f60.dat would not have to carry an extra data file around, the compiled library .dll or .so would work without extra resources for those users.

The most convenient solution would be if the memory area with the data could be accessed with the same function calls fseek, ftell, read as the data in a file. For the application it should make no difference whether it reads an external fle or this memory "file".

Is there a portable solution for this?

Aloist
  • 11
  • 1
  • 2
    It could be that fmemopen() is the solution to my problem. The files are 20 Mbyte each. In the past, 1998, when we first developed the library, it was clear that one would not compile 20 Mb data into the library, but access them as an external file. But nowadays blowing up code by 20 Mb is no big deal, if the data would have to be distributed with the code as a resource file anyway. – Aloist May 15 '21 at 23:22
  • With clang/gcc, you can do something like described here: https://stackoverflow.com/questions/4864866/c-c-with-gcc-statically-add-resource-files-to-executable-library With MSVC on Windows, take a look at ressource files and scripts – lulle2007200 May 15 '21 at 23:23
  • Depending on the type and size of data, it might be viable to include it as a header – lulle2007200 May 15 '21 at 23:24
  • 1
    @Aloist Yes, it looks like `fmemopen` could be used as long as the application uses a library API call to open the file, so that the library can decide whether to call `fopen` or `fmemopen`. However, [this answer](https://stackoverflow.com/a/46837282/3386109) (circa 2017) seems to indicate that `fmemopen` is not supported on Windows unless you have a unix emulator installed. – user3386109 May 15 '21 at 23:29
  • A big problem is that fmemopen does not exist on Windows. Our library is developed and maintaind on Linux. But it must also compile on Windows both for static linking and as dll – Aloist May 16 '21 at 03:18
  • If the data compressed (zip or other) has significantly reduced size, it is worth to do the work on the compressed data and the decompress it a program startup in a memory allocated array of byte. – fpiette May 16 '21 at 08:22

0 Answers0