- Wine-Devel - list.winehq.org

programmable shader research
by Simon Harvey June 3, 2004

June 3, 2004

hello all I have put forward a project proposal outlining a programmable graphics pipeline for optional use in blender. I submitted my proposal: ------------------------------------------------------- PROJECT GOAL I intend to create a render pipeline who's shader(s) can be selected by a user as being a programmable shader created from source code which is then compiled and then "executed" when a pixel is to be shaded OR one of the current stock shaders from a drop down list box in material settings. I have still not yet decided wheather the shading language should be a subset of python (at least looking synthatically similar) or like C (similar to RSL) however the many benifits of an RSL clone is that people have experience with it, it is an industry standard and the shaders runtimes and shader compilers from pixie or aqsis can be used. REQUIRED BLENDER RESOURCES What I hope to use are: The mailing lists - so other developers can have an input on the syntax design as well as give help on pipeline integration and coding techniques. The exposure - so people are aware of it. DECLARATION OF PRIMARY INTENTIONS AND OTHER COMMITMENTS This is a blender research project. There is no agenda of infringing on the foundation's long term plans. HOWEVER It is naturally a big boost to one's own self-esteem and happyness when ones own work gets regonised by the wider community. I am doing a masters in electronics, I do not have the 'promptness' and speed that other coders may have because my thesis takes up so much of my time. Therefore if the project is accepted it should be expected that this is a *long term research project*. With no results to be shown for the first 6-12 months after initial acceptance. My main interest is the shader virtual machine, shader API's and the render pipeline, it will have to be for others to give it a nice GUI if the programmable shader subsystem has the required merit to warrant futher development. The shader type would be the surface shader in renderman(tm), so there is no intention of providing displacement, transformation, atmospheric, volumetric and light shaders to blender's graphics pipeline. -------------------------------------------------- and ton emailed me back asking me to put it on the developer mailing list, just to see what you all thought of it - ask for ideas and comments. so here it is. what do you think?? simon Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com

1 0

debugger symbols and NPTL on RedHat 9
by Shachar Shemesh June 3, 2004

June 3, 2004

Hi all, As mentioned in a previous thread, I'm trying to get a client to migrate their product to Linux using Wine. So far, the results have been so so, with mightily strange results (sockets in "Established" state with no controlling process, zomby processes who's parent is init that are not being cleared, etc.). After some looking around, we tried running Wine with "LD_ASSUME_KERNEL=2.4.1", and the problems magically disappeared. Maybe because of the time that passed since these problems were common, I clean forgot about this option. I noticed that wine-pthread was running instead of wine-kthread, but I did not think of it as a problem beyond a theoretical performance problem. It seems, however, that guessing wrong had pretty dire side effects. So, the question <--------------- Will running wine-kthread directly work? Or is there something crucial done by the "wine" executable? Second problem is probably independant. I figured that going through the process of getting the program compiled as winelib was unnecessary, so I am still compiling it on Windows using Visual Studio. This, naturally, means that it's a PE. After resolving the font problems, I can finally get the program running through winedbg. While I'm doing ok at working like that, the client really prefers working with a GUI. When I try to run the program using the --gdb switch (with or without --no-start), debug symbols for the PE part are not shown. I get all the symbols for the ELF dlls (wine's DLLs), but not for the PE program. Is this a solveable problem? The program is using PDBs for debug symbols, they are not compiled into the PEs. I can change that, I guess, but I would really rather not. Will changing that solve anything? Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/

4 9

Porting Application to MacOS X
by saneh gupta June 3, 2004

June 3, 2004

Hi, I'm on the lookout for a library to port my Windows SDK code to MacOS X. I came across the Wine website and I think this would solve my problem. However before I dive into it, I'd like to get the following clarification : I need my application to be independent of any other binary (like wine) - so, once linked with the required wine-libraries it should just run on any MacOS X machine i.e. no dependency on wine binary/installation. Is this possible? I would also like to use my own makefile for linking in my application with the wine libraries. Is ths fine? Thanks. ________________________________________________________________________ Yahoo! India Matrimony: Find your partner online. http://yahoo.shaadi.com/india-matrimony/

2 1

Re: [MSVCRT] Cross build fix
by Dimitrie O. Paun June 3, 2004

June 3, 2004

On Tue, Jun 01, 2004 at 11:42:28AM +0200, Hans Leidekker wrote: > > Hi, > > This patch: > > http://www.winehq.org/hypermail/wine-cvs/2004/04/0357.html > > broke the MinGW build of msvcrt. The changelog says it's a compatibility > fix. Dimi: what compatibility were you aiming at with this patch? Compatibility with other headers. _WCTYPE_T_DEFINED is in a way part of the public interface, and when we use the headers in Winelib apps, we need to define it so we don't end up with duplicate declarations for wint_t/wctype_t. When we build msvcrt it's a different story of course, and we seem to need the exact opposite. Which is why I find the entire MSVCRT() thing not only ugly, but a bit problematic also. Alexandre, why don't we just remove all those MSVCRT() macros, use the headers in Winelib apps, and duplicate what we need with a MSVCRT_ prefix in an internal header that we use just for building? These things are quite stable, so the risk of diverging is small, and for thinks like structures we can write tests to make sure we have the same sizes/layouts. -- Dimi. P.S. Please note that in theory the same situation holds true for all the other sentries. So it's not like we only have a problem with wint_t/wctype_t.

3 7

Re: Don't send messages when doing a ShowWindow(SW_HIDE) on an invisible window
by Dmitry Timoshkov June 3, 2004

June 3, 2004

"Mike Hearn" <mh(a)codeweavers.com> wrote: > This fixes TightVNC. Praise be to open source Windows apps! :) > > Mike Hearn <mh(a)codeweavers.com> > Don't send WM_SIZE, WM_MOVE nor WM_WINDOWPOSCHANGING in ShowWindow when > hiding an invisible window. Add a test for this behaviour which passes on > Windows 2000 and Wine. I think the real fix should be to test WS_VISIBLE style in ShowWindow and do nothing for SW_HIDE && !WS_VISIBLE, or SW_SHOWxxx && WS_VISIBLE. At least "Windows internals" book shows that Windows does that test. -- Dmitry.

1 0

dlls/d3dxof/d3dxof and unused functions
by Gerald Pfeifer June 3, 2004

June 3, 2004

The addition of /wine/dlls/d3dxof/d3dxof.c revision 1.1 date: 2004/06/03 00:03:23; author: julliard; state: Exp; Christian Costa <titan.costa(a)wanadoo.fr> Added d3dxof dll, part of Direct3D. causes the following warning regressions: d3dxof.c:238: warning: `IDirectXFileBinary_Vtbl' defined but not used d3dxof.c:453: warning: `IDirectXFileDataReference_Vtbl' defined but not used d3dxof.c:612: warning: `IDirectXFileObject_Vtbl' defined but not used d3dxof.c:690: warning: `IDirectXFileSaveObject_Vtbl' defined but not used Would you mind addressing these? Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

1 0

HELP
by mguyard June 3, 2004

June 3, 2004

I've developped a software with Windows Visual C++, i want to export it into Linux Red Hat 9.0. My idea was to use Wine and WineLib. So i import wine with command below: export CVROOT=\ :pserver:cvs(a)cvs.winehq.com:/home/wine cvs login # type "cvs" as the password cvs co wine cd wine ./configure && make The wine installation was performed correctly so i wanted to test wine and more exactly winemaker. Run <command>make clean</command> in the winemine source directory if it contains results of previous builds. Create a separate directory with name winemine2, so it won't conflict with the Wine copy of the application. Copy the sources of winemine (files *.c, *.h, *.rc) to this directory. Now run the commands, mentioned above from the winemine2 directory: </para> <programlisting> $ winemaker --lower-uppercase . ------> but i was quite disapointed when it said me : bash: winemaker: command not found That's why i call you to know how can i do to work winemaker? Thank you very much Bests regards Mickael GUYARD INTA engineer 144 bd Pereire Paris Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34/mn) ; tél : 08 92 68 13 50 (0,34/mn)

1 0

Performance issues with Wine application
by Ewert, Mark June 3, 2004

June 3, 2004

Hi All, I have a simulation tool that runs under windows NT/2K directly from the DOS command shell. When running it on a Windows machine I get 200 cycle/s. When running it on Linux via Wine I get ~10 cycle/s. I didn't realize Wine would have such a negative performance impact. Is there any way to trace where the performance bottleneck is? I actually don't have access to the source of the simulation tool, so any optimizations would have to be done directly in Wine. I should also mention that to get this application to work with Wine I had to copy over the Microsoft visual c++ dll: msvcp60.dll. Would this somehow be impacting the execution performance? By the way, I'm not sure if this is the right mail list for discussing performance issues. I tried the end user mail list but did not get a response from anyone.

3 2

Re: Crash due to _fini
by Dimitrie O. Paun June 2, 2004

June 2, 2004

On Tue, Jun 01, 2004 at 08:40:09AM +0530, Rajeev Bansal wrote: > thanks for reply > > i used wineg++ also but result was the same as wineg++ is link to winegcc > lrwxrwxrwx 1 root root 7 May 25 17:34 wineg++ -> winegcc Can you please come up with a short test case? -- Dimi.

1 0

FW: Crash due to _fini
by Rajeev Bansal June 2, 2004

June 2, 2004

Hi Dimi, I was trying to understand why any wine shared dll (like msvcrt.dll.so) crashed at the _fini call. This does not happen if I use my own created shared libraries. I was seeking help to find out why the crash occurs only with wine shared library. I had to port my windows code even on MacOS, hence I was attempting to use the wine libs without winegcc/wineg++ and specs file. This would make "porting" to any platform not supported currently by wine easy. Thanks rajeev -----Original Message----- From: Dimitrie O. Paun [mailto:dpaun(a)rogers.com] Sent: Monday, May 31, 2004 11:24 PM To: Rajeev Bansal Cc: wine-devel(a)winehq.org Subject: Re: Crash due to _fini On Mon, May 31, 2004 at 05:16:47PM +0530, Rajeev Bansal wrote: > Please tell me a way so that i can use wine libraries directly without > winegcc or specs file Please don't do that. Or if you do, I'm afraid we can't help you. > on using winegcc for code which contains new and delete operator it gives > undefined reference to following symbols > operator new(unsigned) > operator delete[](void*) > _Unwind_Resume > __gxx_personality_v0 > > please help me to resolve above symbols Use wineg++ to compile and link. -- Dimi. --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.642 / Virus Database: 410 - Release Date: 3/24/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.642 / Virus Database: 410 - Release Date: 3/24/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.642 / Virus Database: 410 - Release Date: 3/24/2004

2 1