gdi32 and wine

Mike Hearn mike at theoretic.com
Fri Apr 4 12:07:53 CST 2003


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 <kk_singh at yahoo.com> 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
>  
> 
> 




More information about the wine-devel mailing list