Re: Baby X is bor nagain

On 12/06/2024 07:40, Bonita Montero wrote:

Am 11.06.2024 um 18:15 schrieb Malcolm McLean:
 

These are Baby programs. But they use a cut down GUI. So they need to get fonts and images into the program somehow. And so Baby X does that by converting to 32 bit C arrays which can be compiled and linked as normal. And for that, you need a tool. Writing a tiff file decoder is not a trivial exercise.

 I converted my code into sth. that produces a C-string as an output.
Printing that is still very fast, i.e. the files produced are written
with about 2.6GiB/s. But the problem is still that all compilers don't
parse large files but quit with an out of memory error. So having a
.obj output along with a small header file would be the best.
 

How big files are you talking about?  In an earlier thread (which I thought had beaten this topic to death), "xxd -i" include files were fine to at least a few tens of megabytes with gcc.  And it would be, IMHO, absurd to have much bigger files than that embedded with your executable in this manner.  I can understand wanting some icons and a few resource files in a PC executable, but if you have a lot of files or big files then a single massive executable often does not make much sense as the binary file.
If you /do/ want such a file, it is typically for making a portable package that can be run directly without installing.  But then you don't mess around with inventing your own little pretend file systems, or embedding the files manually, or using absurd ideas like XML text strings.   You use standard, well-established solutions and tools such as AppImage on Linux or self-extracting zip files on Windows.