Hi, Damjan Jovanovic
Thank you tired of the answer to my questions.
I carefully read the wine part of the code and development document,
searched in mail lists, these days.
And I got some inspiration from wine plugin API wiki page and wine loader's
code.
I am considering of an approach.
Link preloader and related resource(libwine) with my Linux native App.
Do some modify with wine_init function, and call it before main().
This can be implemented by a global C++ objects's constructor.
Upper two steps can deal with TEP and FS register.
But I there may be another problem.
If there was aready an static global C++ object in my App,
How can I makde it initiatited after wine_init from in object.
Do you have some other expostulate of this idea?
BTW, I skim over mplayer and xine's parts of code.
They don't dealwith TEB and FS register.
They only do sth on LDT and allocat PE header before LoadeLibaray.
Why they can run correctly???
2007/8/22, Damjan Jovanovic <damjan.jov(a)gmail.com>:
>
> On 8/21/07, trulyliu <trulyliu(a)gmail.com> wrote:
> >
> >
> >
> > 2007/8/21, Damjan Jovanovic <damjan.jov(a)gmail.com>:
> > > On 8/21/07, trulyliu <trulyliu(a)gmail.com> wrote:
> > > >
> > > >
> > > > 2007/8/21, Damjan Jovanovic <damjan.jov(a)gmail.com>:
> > > > > On 8/21/07, trulyliu <trulyliu(a)gmail.com> wrote:
> > > > > > Can I made Arithmetic.dll.so ? And link it against my linux App?
> > > > >
> > > > > A library function runs in the context of the process that invokes
> it.
> > > > > A library doesn't have its own TEB/memory layout/exception
> handling
> > > > > that works independently of the process that calls it, no matter
> how
> > > > > it is compiled. If the wine plugin API is ever made, it will
> modify
> > > > > the process so it has what the library expects when the library
> > > > > functions are called.
> > > > >
> > > > > Does your Arithmetic.dll.so call any Windows functions? If so, you
> > > > > need wine and you will always need wine, plugin API or no plugin
> API,
> > > > > whether you compile it into a DLL or .dll.so. But if you only use
> ANCI
> > > > > C stuff you can compile it into a .so and use it without wine.
> > > > >
> > > > > If you want something that runs seamlessly on every operating
> system
> > > > > today, IMHO you should consider Java.
> > > > >
> > > > >
> > > >
> > > >
> > > > Yes, Java may be a good choice for crossing platform.
> > > >
> > > > As you said, my Arithmetic.dll does not call any windows function.
> > > > It's pure ANSI C library. What's the step of make .dll.so ??
> > > >
> > > > Use winegcc or gcc ??
> > >
> > > Use gcc and make a .so like this:
> > > gcc -c arithmetic.c -fPIC
> > > gcc arithmetic.o -shared -o arithmetic.so
> > >
> > > Then put it in /usr/lib and link to it like so:
> > > gcc -c application.c
> > > gcc application.o -o application -larithmetic
> > >
> > > > > > --
> > > > > > trulyliu(a)gmail.com
> > > > > Damjan
> > > > --
> > > > trulyliu(a)gmail.com
> > > >
> > >
> > > Damjan
> >
> > gcc -c arithmetic.c -fPIC ???
> > I am sorry. I don't have Arithmetic.dll's source code.
> > Can I use LoadLibaray() and GetProcAddress
> > to get the function which Arithmetic.dll exports.
>
> No, for the reasons I talked about before. Eg. GetProcAddress() does
> look up the current directory, which resides in the TEB, which AFAIK
> resides in the FS CPU register on Windows. On Linux the FS register
> contains something else, leading to a crash.
>
> At the moment, you can only use Windows DLLs from Windows applications
> or from winelibs, which are Windows applications compiled to be able
> to use Linux libraries as well.
>
> > --
> > trulyliu(a)gmail.com
> >
>
> Damjan
>
--
trulyliu(a)gmail.com