Hi Tom, (and everyone else) Earlier today I released a big update to one of my programs PGME. But, this isn’t really about it specifically.
It’s actually regarding the discussion we had on the mailing list a few weeks back involving NLS support. But, I feel a little back/side story is in order. PGME “ships” two ways. One version is wrapped up in a package. The other (and for reasons I don’t feel like going into, preferred version) has its own installer. This one EXE includes all the data for the roughly 70 files (binaries, themes, languages, fonts, screen savers, etc) Prior to the current release, the process of gluing the “installer” together into a single large EXE was a little clunky. It needed compiled twice and two separate helpers programs to jam it all together. For the new release, I decided to change/fix that. Which finally brings me to the actual point. I implemented a simple format based on the idea I had during the discussion on NLS for attaching file data to executables. Obviously, this is not a new idea. But unlike other heavy implementations of doing it, this “standard” is very lightweight and extremely compatible. It can be used to “tack” data onto nearly any file. EXE, COM and even text and other “static” files. It is very easy to “pull” resources from your own program. Along with this “standard”, I created a utility called QResFile. It is one of the “extra” tools that comes with PGME. This utility can list, import, export and remove files from the pool of data that gets glued to the executable. The PGME installer has been updated to use the new “standard”. And when I have a few spare minutes, I will update the installer to use translation files and fonts from the attached resource pool. So, there now exists a simple format and a utility to manage attached files. It can be used for nearly anything. Including, attaching language translation to executables. Wether or not anyone wants to use my tool or format “standard” to glue translations or other data to their code, that’s an completely different matter. Did I mention you can even UPX compress your binaries and still use this method? For EXE’s, you’d want to compress the EXE then glue on your attachments (I haven’t tried gluing and then compressing. I guess it comes down to what UPX does when it hits the resource blob. Might work. IDK). For COM files, you’d probably want to glue them then compress. That way you don’t need to mess around with having any overhead of loading them. On a side note… You can also use the utility to unglue everything. So, you can still use UPX to uncompress binaries if needed. Oh, if you want to glue data to a text file, I highly recommended sticking a EOF character at the end first. Then you can “TYPE” them without seeing all the stuff glued onto it. But, it’s really meant for binaries. There are a couple things I haven’t added to the utility yet. Namely, the ability to delete a single item from the resource pool. Update/replace an entry. Or, prevent duplication and collision of resource items. I’ll probably add that eventually. But the functions I mentioned earlier all work good. For now, the rest mostly comes down to adoption. Anyhow, both QResFile.exe and readme/spec document (QResFile.en & .fr) are included with PGME. https://up.lod.bz/PGME Or, if you just want to look at the hastily written, uncomplicated and easy to implement spec… you can fetch it from the FD-NLS project under https://github.com/shidel/fd-nls/tree/master/pgme/docs :-) Jerome ( Ps. Why did I type this on my phone when I was 5ft from my computer? It took forever. Ugh. )
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
