Re: gdi32 and wine

[Rolf Kalbermatter]

KK singh  wrote:
> > KK> I am not using any of these in native form...
>
> You *are* using such a dll. It's called...
>
> ATMLIB.DLL
>
> Find out, what dll or application requires this
> system
> component, which clearly will never work under Wine.

KK > **NEVER** is bit challenging !!!

I agree it is a strong statement, but probably not very
far from the truth.

KK > What if the required functions are implemented in
KK > gdi32.dll ?

Chances are very high that with every new function you implement
even as stub you just run into the next missing export! Also a
stub implementation may work for some functions, but more sooner
than later you end up with really bad functionality in the caller.

KK > This one seems to raise the issue of 
KK > changing other builtin libraries, But some hack 
KK > should exist.
KK > What if a builtin implementation of ATMLIB.dll is
KK > written, which doesnt use the missing functions.

Mmmh, are you proposing to write it? This library looks to me
like a full featured font type manager and then some. Does a
full API description exist at all? How big are the chances,
that implementing such a library will conflict sooner or
later with patents of some sort?
And you may be ending up reimplementing substantial parts of
things Ghostscript or similar packages already do.

Rolf Kalbermatter

gdi32 and wine

[Mike Hearn]

ATMLIB isn't a Microsoft DLL is it? So why is it making undocumented
calls? I think if this is actually an Adobe lib, then working through
the unimplemented functions is certainly possible.

On Fri, 2003-04-04 at 19:31, Rolf Kalbermatter wrote:
> KK singh  wrote:
> > > KK> I am not using any of these in native form...
> >
> > You *are* using such a dll. It's called...
> >
> > ATMLIB.DLL
> >
> > Find out, what dll or application requires this
> > system
> > component, which clearly will never work under Wine.
>
> KK > **NEVER** is bit challenging !!!
>
> I agree it is a strong statement, but probably not very
> far from the truth.
>
> KK > What if the required functions are implemented in
> KK > gdi32.dll ?
>
> Chances are very high that with every new function you implement
> even as stub you just run into the next missing export! Also a
> stub implementation may work for some functions, but more sooner
> than later you end up with really bad functionality in the caller.
>
> KK > This one seems to raise the issue of 
> KK > changing other builtin libraries, But some hack 
> KK > should exist.
> KK > What if a builtin implementation of ATMLIB.dll is
> KK > written, which doesnt use the missing functions.
>
> Mmmh, are you proposing to write it? This library looks to me
> like a full featured font type manager and then some. Does a
> full API description exist at all? How big are the chances,
> that implementing such a library will conflict sooner or
> later with patents of some sort?
> And you may be ending up reimplementing substantial parts of
> things Ghostscript or similar packages already do.
>
> Rolf Kalbermatter

gdi32 and wine

[Rolf Kalbermatter]

Mike Hearn wrote:
> ATMLIB isn't a Microsoft DLL is it? So why is it making undocumented
> calls? I think if this is actually an Adobe lib, then working through
> the unimplemented functions is certainly possible.

No, it is indeed an Adobe lib, but it is standard installed with
Windows NT/2K and XP as far as I know. This does however probably
mean that there has been close cooperation between Adobe and MS
for this lib, which may or may not imply many undocumented calls
to core Windows DLLs.

It is a small DLL however so it does not seem to implement so much.
Only it has a compagnon atmfd.dll which is much larger.

I have also found some references on the web that the MS installation
does not include a specific registry setting, so that the DLL will
refuse to convert copyrighted Type1 fonts into TrueType and make
them not usable in any but the Adobe applications! And a probably
outdated API description from Adobe from 1998!

Rolf Kalbermatter