Hi Tom,
> On Aug 16, 2021, at 4:33 AM, tom ehlert <t...@drivesnapshot.de> wrote:
> [..]
> I stopped reading, sorry.
> you should realy have a TLDR section.
I don’t blame you there. Thats the really, really long “User’s Manual” for PGME
itself. You’d have probably really angry if you read the entire thing. Mostly,
cause that isn’t covered in that document. The “spec" is only the covered
QRESFILE.* (* being language) documents.
> so you developed a hugely complex, turing
> complete program to attach binary data to programs (similar to what KITTENC
> does) and propose to use *this* instead of KITTENC.
I have nothing against kitten. However, I’m not a fan of using the
“0.1,4.2,etc” method of storing NLS resources. I much prefer my own string
resource management schemes that I’ve used since the 80’s. It’s similar. But,
is allows using text based keys for the strings. This like
“ERROR.15,WARN-LOW-MEM,etc”
So, I’ve never used KITTEN for anything, don’t follow its development and was
not aware of the existence of KITTENC.
But, I just downloaded a copy of the new version of KITTEN from the ibiblio
mirror and skimmed the code for comparison.
The method used is nearly identical. There are differences in implementation.
Each have a footer that contains an file ID tag and points to the first chunk
of data. Those chunks have some sort of TAG to identify them, contain a method
to know where the next chunk is located.
Format comparison:
XBINRSRC footer: KITTENC footer:
word block_id // Zero for terminating block
long filepos // points to content
dword first_block long resource_count // number of entries
long fileend_orig // file end NOW because of UPX
char ID[10] char ID[8] // Format ID tag XBINRSCRv1 or
KITTENC
16 bytes 24 bytes
XBINRSRC file: KITTENC file:
word block_id // 0001h for file data
dword block_size // Total size of this block
byte attr // DOS file atribute
dword time // DOS packed timestamp
dword filesize // Size of file, (could be
computed by analyzing this block)
byte length_of_name // Length of resource ID string
(simplifies reading in pascal)
char name[?] // Characters of name 0-255
bytes
byte null // Zero terminator (simplifies
reading as ASCIIz)
char language[4] // 4 byte language id
long filepos_start // beginning of data
long filepos_end // end of data
long reserved // byte alignment
byte data[?] byte data[?] // file contents
17-270 bytes + file 16 bytes + file
XBINRSRC NLS data: KITTENC NLS:
short len
short id
bytes message[?]
left to program no
library to read is
provided at present
More comparison on features:
XBINRSRC KITTENC
increase in size a little more a little less
overall ease of use about the same about the same
direct NLS support not at present easy
other files support yes no
other data types yes no
format extension yes no
So, overall they are very similar. But, if you like how KITTEN references
strings and have no need
to attach non-translations, you should stick with KITTEN. On the other hand, if
you prefer a different
method (like ‘FATAL.ERROR=“) or want to attach other types of files then
XBINRSRC (QResFile)
is the way to go.
> may I ask, whether it is KITTEN compatible with very tiny additional
> work?
The QResFile program could be made compatible with both.
> is it scriptable?
Absolutely.
> what's the size increase for programs?
About the same.
> what's
> the overhead on memory use?
About the same.
> BTW: KITTENC is compatible with UPX, both before and after compression
> (I *DO* know)
The resource can be attached to a compressed or uncompressed EXE/BIN. But
for EXE’s, compressing the binary after attaching them results in the EXE being
unable to retrieve the data from it’s file. I’ll probably do a rev-2 to the
spec today to
include a none-upx end of file value in the footer.
>
>> 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.
>
> this is all about a free and open DOS. so text files should be
> changable by others. very bad as the glue data will be lost after
> editing text files :<
I agree.
It is generally a very bad idea to glue stuff onto text files. It’s a great way
to encourage data loss.
Mostly, I was just pointing out it “could” be done and nothing would stop you
from doing it.
There is one really possible exception to that. You could do a “prepend" of
some little
bit of text for a data resource file that described what it is. For example, if
had an
external file that contained a bunch of sprites for a game called
“SPRITES.DAT”,
you could have it start with plain text saying “contains character images for
my game”.
But, even that would be better served by a readme and good documentation.
>
> Tom
:-)
Jerome
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
