CreateScalableFontResource - a few questions

[Chris Howe]

Hi all,

For my first foray into contributing to Wine (a blast, so far :) )
I am implementing CreateScalableFontResource which is
currently present in stub form, but when fully implemented
should create .FOT files from .TTF files for (amongst other
things) temporarily installing fonts by a successive call to
AddFontResource (which exists in Wine).

It was trivial to code the functionality for the flow of
CreateScalableFontResource as per the documentation
but my research into the .FOT file format threw up a couple
of questions.

Even though .FOT files, as far as they're used by
AddFontResource are little more than storage for a couple
of pathnames, they are in fact Win3.1-style NE-binary files.
With that in mind,

1) AFAICT, there is no code in Wine currently to save
NE-binaries to disk, although obviously they are loadable
and data structures relating to the format are defined. Rather
than write a standalone, .FOT saving function, based off the
kind of code you see in the fnt2fon program - .FON files
are a similar, though not identical format - would it be better
to write something like a NE_SaveModule that takes an
in-memory NE module and saves it to disk, and call that from
my .FOT saving code?

This would live in ne_module.c I guess, and be limited, certainly
initially, to the context in which I'd be using it. IE, just saving the
resources. Indeed, I don't know in what other context that code
WOULD be used, but who knows, down the line someone
might want to expand it to do something more useful.

2) NE binaries, including FOT files, contain as part of the header
a DOS stub-executable that typically spits out a message of
some sort. I reasoned that being in itself a compiled binary we can't
legally use the blob of binary that would appear in a real-world FOT
file as-is, and I certainly wasn't about to go decompiling it, so I lifted
the DOS stub executable from fnt2fon which I'm assuming as it's
distributed with WINE is fair game.

This will mean .FOT files generated by my code will be slightly different
to a real, "in-the-wild" .FOT file, but I'm not sure in the circumstances
that matters as the file is typically temporary, and only used as a
container, never to be run -  it's just different from a user perspective.
Is
this OK?

Also, are there any open-source requirements on that small binary blob?
Fnt2fon certainly includes it with no added info.

3) Related to item 2, so far, the actual spec of the .FOT file format has
eluded me, though knowing that it's a NE binary has enabled me to
reverse a lot of it, which I'm yet to test but I believe will be enough to
fool
AddFontResource into doing what it's supposed to do. Again, is it
enough to go that far for now as the FOT format seems to be unsupported
in WINE?

Advice on these points would help me help you :)

--
Chris Howe

[Dmitry Timoshkov]

"Chris Howe"  wrote:
> - NE binaries, including FOT files, contain as part of the header
>
> a DOS stub-executable that typically spits out a message of
> some sort. I reasoned that being in itself a compiled binary we can't
> legally use the blob of binary that would appear in a real-world FOT
> file as-is, and I certainly wasn't about to go decompiling it, so I lifted
> the DOS stub executable from fnt2fon which I'm assuming as it's
> distributed with WINE is fair game.

You can find a much more simpler DOS stub in dlls/kernel32/tests/loader.c,
or borrow the code from dlls/setupapi/fakedll.c,build_fake_dll() in order to
be able to add a description string into the header like "Wine placeholder DLL".