August 2007 - Wine-Devel - list.winehq.org

Re: How to Calling PE Dlls on linux??

by trulyliu

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(a)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(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 <http://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 <http://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 > -- trulyliu(a)gmail.com

Aug. 22, 2007

Re: [2/5] WineD3D: Refuse to lock locked surfaces

by H. Verbeet

On 22/08/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Spotted by DCT > I don't know what the DCT actually tests, but should it refuse to lock any locked surface, or only when the rectangles overlap? Of course a test would be nice, considering surface locking behaves somewhat different between ddraw, d3d8 and d3d9.

Aug. 22, 2007

Re: How to Calling PE Dlls on linux??

by trulyliu

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

Aug. 22, 2007

Re: Changing Bugzilla settings so a single person can't confirm bugs by "popular vote"

by Scott Ritchie

If there's a way to set it such that confirmation (and only confirmation) ignores all but 1 of an individual's votes, that would be ideal. Thanks, Scott Ritchie On Wed, 2007-08-22 at 00:02 -0700, Lei Zhang wrote: > Agreed, quite a few bugs have been confirmed in this manner. > > On 8/21/07, Kai Blin <kai.blin(a)gmail.com> wrote: > > Hi folks, > > > > While working on bug 9405, I realized that all 20 votes on that bug were made > > by the reporter. I think that's pretty lame, so I've asked the bugzilla folks > > if there's a way to fix that. They said that the settings should be obvious > > when editing the product. Can we please fix that? > > > > Cheers, > > Kai > > > > -- > > Kai Blin > > WorldForge developer http://www.worldforge.org/ > > Wine developer http://wiki.winehq.org/KaiBlin > > Samba team member http://www.samba.org/samba/team/ > > -- > > Will code for cotton. > > > > > > > > > > > >

Aug. 22, 2007

Re: Changing Bugzilla settings so a single person can't confirm bugs by "popular vote"

by Lei Zhang

Agreed, quite a few bugs have been confirmed in this manner. On 8/21/07, Kai Blin <kai.blin(a)gmail.com> wrote: > Hi folks, > > While working on bug 9405, I realized that all 20 votes on that bug were made > by the reporter. I think that's pretty lame, so I've asked the bugzilla folks > if there's a way to fix that. They said that the settings should be obvious > when editing the product. Can we please fix that? > > Cheers, > Kai > > -- > Kai Blin > WorldForge developer http://www.worldforge.org/ > Wine developer http://wiki.winehq.org/KaiBlin > Samba team member http://www.samba.org/samba/team/ > -- > Will code for cotton. > > > > >

Aug. 22, 2007

Changing Bugzilla settings so a single person can't confirm bugs by "popular vote"

by Kai Blin

Hi folks, While working on bug 9405, I realized that all 20 votes on that bug were made by the reporter. I think that's pretty lame, so I've asked the bugzilla folks if there's a way to fix that. They said that the settings should be obvious when editing the product. Can we please fix that? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Aug. 22, 2007

Re: [kernel32/tests] Skip some not implemented functions and add a few skip's

by Paul Vriens

Francois Gouget wrote: > On Tue, 21 Aug 2007, Paul Vriens wrote: > >> Hi, >> >> GetTempPathW is not implemented on win9x. > > I did not actually read the test but it sounds like GetTempPathW() is > not actually essential to the test. Could we replace it with another way > to get the path for a temporary directory? Maybe even hard-code one, > maybe adding the process id to make it somewhat unique? > > There are several W-calls after that so I think we should be save here as it will most likely not run on win9x only. Changing that one will mean we have to bail out a bit later. So, yes it's not essential to the test but the W-calls are needed currently. We could of course rewrite the test to use A calls but I'm not sure if we want to go that way? -- Cheers, Paul.

Aug. 22, 2007

Compositing GL

by Chris Robinson

Over the past several days, I've been working with some people in #winehackers on a way to help solve the problems Wine faces with OpenGL.. namely the lack of useable onscreen pixel formats and broken child windown rendering. Here's a patch for your perusal in hopes to generate feedback. What this does is, it renders GL to an offscreen buffer the size of the window it's rendering to, first trying a redirected window (if you have the Xcomposite extension), then falling back to GLXPixmaps (which may be slower, especially if you don't have AIGLX). The offscreen buffer is then copied to the window it should be displaying on using X, acting in a manner nearly identical to how Vista composites OpenGL (as described here: http://www.opengl.org/pipeline/article/vol003_7/ ). Given that it uses X to do the final composite, it obeys all clipping regions, which means it works even on obscured child windows. And since it's offscreen, it won't interfere with, or be bothered by, Wine's window. It also allows it to use other visuals/pixel formats than Wine's window (not done in this patch yet). There is a speed hit, however. The DX9 swap chains demo, which gets about 280 FPS for me normally, gets about 80 to 90 FPS with the compositing method. It seems to be a ceiling though, as other more GPU intense apps have no extra noticeable slow down. Still, as an optimization, it can render directly to the window when it's being used on the whole window and the selected pixel format matches the current visual (this bit is disabled in the patch since it's for testing offscreen rendering, but it's simple to re-enable). Further, a registry setting (HKCU\Software\Wine\X11 Driver\CompositeGL) can be used to force GL compositing off to give you the current behavior (single onscreen pixel format, broken child window rendering). This obviously isn't the final patch, however it's likely what the final result will be like, forgoing unforeseen issues. Questions and comments are welcome.

Aug. 22, 2007

Re: [1/2] wined3d: Restore a line that got lost

by Stefan Dösinger

Am Dienstag, 21. August 2007 23:22 schrieb H. Verbeet: > This got lost by commit 92ce028a0b3aba513f8fb62d7021533896cd99f6. > > Changelog: > - Restore a line that got lost Actually I think we can remove that whole codeblock now. stateblock::apply and stateblock::capture have the needed states hardcoded now for _ALL, _VERTEX and _PIXEL stateblocks.

Aug. 21, 2007

Re: [kernel32/tests] Skip some not implemented functions and add a few skip's

by Francois Gouget

On Tue, 21 Aug 2007, Paul Vriens wrote: > Hi, > > GetTempPathW is not implemented on win9x. I did not actually read the test but it sounds like GetTempPathW() is not actually essential to the test. Could we replace it with another way to get the path for a temporary directory? Maybe even hard-code one, maybe adding the process id to make it somewhat unique? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

Aug. 21, 2007