The issue of the order of global  C++ object's constrution has been metioned
in wine development guid section 8.3.3.Starting a Winelib process
 
For the first scheme,
how can we made win_init as the entry of .init section.
Implement like .strat() in preloader.c ????
 

 
2007/8/22, trulyliu <trulyliu@gmail.com>:
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@gmail.com>:
On 8/21/07, trulyliu < trulyliu@gmail.com> wrote:
>
>
>
> 2007/8/21, Damjan Jovanovic <damjan.jov@gmail.com >:
> > On 8/21/07, trulyliu <trulyliu@gmail.com> wrote:
> > >
> > >
> > > 2007/8/21, Damjan Jovanovic <damjan.jov@gmail.com>:
> > > > On 8/21/07, trulyliu < trulyliu@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@gmail.com
> > > > Damjan
> > > --
> > > trulyliu@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@gmail.com
>

Damjan



--
trulyliu@gmail.com



--
trulyliu@gmail.com