June 2004 - Wine-devel - list.winehq.org

Re: Tab control TCM_SETITEMEXTRA (bugzilla #1046)
by Alexandre Julliard 04 Jun '04

04 Jun '04

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > @@ -2557,8 +2562,10 @@ > infoPtr->items[iItem].iImage = pti->iImage; > > if (pti->mask & TCIF_PARAM) > - infoPtr->items[iItem].lParam = pti->lParam; > - > + memcpy(&infoPtr->items[iItem].lParam, &pti->lParam, infoPtr->cbInfo); > + else > + memset(&infoPtr->items[iItem].lParam, 0, infoPtr->cbInfo); That doesn't look right at all, lParam is not at the end of the structure. And the variable-size info should really be a byte array or something similar, not an LPARAM. -- Alexandre Julliard julliard(a)winehq.org

3 4

segfault at startup
by terra＠gnome.org 04 Jun '04

04 Jun '04

It looks like it is blowing the stack. Ideas? Morten gdb loader/wine-pthread ...] (gdb) where #0 0x4010afdc in _int_malloc () from /lib/libc.so.6 #1 0x4010a18c in malloc () from /lib/libc.so.6 #2 0x404adb72 in _xmalloc (size=25) at ../../misc/registry.c:95 #3 0x404aeb24 in _w95_dump_dke (key_name=0x4055470c "", creg=0x405c0000, rgkn=0x405c0020, dke=0x406444d4, f=0x77f04f60, level=0) at ../../misc/registry.c:717 #4 0x404aeba7 in _w95_dump_dke (key_name=0x4055470c "", creg=0x405c0000, rgkn=0x405c0020, dke=0x4064449c, f=0x77f04f60, level=0) at ../../misc/registry.c:725 #5 0x404aeba7 in _w95_dump_dke (key_name=0x4055470c "", creg=0x405c0000, rgkn=0x405c0020, dke=0x40644464, f=0x77f04f60, level=0) at ../../misc/registry.c:725 #6 0x404aeba7 in _w95_dump_dke (key_name=0x4055470c "", creg=0x405c0000, rgkn=0x405c0020, dke=0x4064442c, f=0x77f04f60, level=0) at ../../misc/registry.c:725 [...] (gdb) p *dkh $1 = {nextkeyoff = 86, nrLS = 188, nrMS = 75, bytesused = 86, keynamelen = 23, values = 1, xx1 = 0, name = "I"} (gdb) p *dke $2 = {x1 = 0, hash = 0, x3 = 0, prevlvl = 0, nextsub = 1, next = 0, nrLS = 0, nrMS = 0} Note dke->next==0.

3 3

Re: Listview ignores the user specified image state index
by Dimitrie O. Paun 04 Jun '04

04 Jun '04

On Thu, Jun 03, 2004 at 02:12:49PM -0700, Krishna Murthy wrote: > While inserting the item in ListView control in wine( in function > ISTVIEW_InsertItemT() ), the state image index is overwritten with zeros. > After copying the LVITEM structure to newly created item in > LISTVIEW_InsertItemT(), a statement is unnecessarily masking the state with > LVIS_STATEIMAGEMASK by using ~ operator (item.state &= ~LVIS_STATEIMAGEMASK; > ). This statement is making the bits 12 through 15 overwrite with 0's by > replacing original state image index. Odd, I've added that, but I can not understand why. If anything, it might be a typo, as I can't see why I would want to nuke the state image, but I also can not remember what I wanted to remove. So the patch is OK, I'll think some more tonight what, if anything, I wanted to remove from the state. -- Dimi.

1 1

Re: Don't send messages when doing a ShowWindow(SW_HIDE) on aninvisible window
by Dmitry Timoshkov 04 Jun '04

04 Jun '04

"Mike Hearn" <mh(a)codeweavers.com> wrote: > OK, I sent a fixed patch to wine-patches. I thought ShowWindow/SWP might > do extra things we didn't want to skip, but if the Windows Internals > book says this is what Windows does then we can do that too. On Windows > it returns FALSE if you do that anyway, so it's probably right. FALSE returned by ShowWindow doesn't mean a failure. ShowWindow returns previous visibility status, and FALSE means that a window was invisible. > By the way how much is "Windows Internals"? Is it still sold? I should > look into getting a copy. I bought russian translation of the book in 1995. Original book was published in 1993 by Addison-Wesley, ISBN 0-201-62217-3. -- Dmitry.

1 0

Request for winetesting volunteers
by Chris Morgan 03 Jun '04

03 Jun '04

Thanks to Brian Vincent, Paul Millar, Dimi Paun, Ferenc Wagner and Kevin Koltzau the automated winetest suite is ready for more widespread testing. Kevin and Paul build winetests each night if there were cvs commits since the last time the tests were built. The winetests are published to a script on winehq that Brian and Dimi wrote. The winrash service that I wrote sends its current state to the service and receives a script to process that may direct it to check in later, download a winetest and run it or upgrade itself. Thanks to Ferenc the winetest results are sent back to winehq and can be accessed via http://test.winehq.org/data/ Pretty formatting of the results is coming soon ;-) We need volunteers that are willing to particpate in the winetesting process by running the winrash service on their computers. The winrash installer can be downloaded from: http://prdownloads.sourceforge.net/winrash/winrash-0007-chris-msvc.exe?down… You can find out more about winrash at http://winrash.sf.net The installer will install winrash as a service and run Wine tests as required. It is IMPORTANT that you set the client id correctly. Please use your first and last name WITHOUT spaces, like JohnSmith. Using the default client id will cause your winetest results to be ignored. The service is smart enough to autoupgrade as new versions are released. To uninstall just go to the Add/Remove programs and click 'remove' as you do for many windows programs. There is the ability to restrict the times when winrash runs winetests but this requires manually adding some keys to the registry. I haven't finished testing this feature but if someone wants it I can see about getting it polished up and in a release early this coming week. We currently need testers for the whole range of windows versions, win95/98/me, nt3/4, win2k, xp and 2003. Please reply if you want to help out so that we know what kind of coverage we can expect. The more the merrier, so please sign up even if others have done so for your version of Windows. Chris

3 5

Re: Re: Request for winetesting volunteers
by chmorgan＠charter.net 03 Jun '04

03 Jun '04

I think we should switch the winrash id field from the users first and last name to an email address we can contact the user at. There are a few odd errors that I'd like to get more information about but its difficult to contact people via their first and last name. Any objections to this? Winetest able to handle an email address as the username field? Chris > > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Date: 2004/06/03 Thu AM 01:30:05 EDT > To: Ferenc Wagner <wferi(a)afavant.elte.hu> > CC: wine-devel(a)winehq.org > Subject: Re: Request for winetesting volunteers > > On Sat, May 29, 2004 at 09:22:02AM +0200, Ferenc Wagner wrote: > > What's missing, what should be easier? > > Now that you're asking: in the reports, I don't quite like > that a single report for Win95 is listed as OSR2 in the > main summary, but then it switches to Win95(n) when we have > more than one. Similarly for Win98. This is very confusing. > > For example, after the first submitted tests, the main > summary header read: > > OSR2 SE ME .... > > I wasn't even sure what SE was. Anyway, I think the header > should remain immutable: > > Win95 Win98 ME NT3 NT4 2000 XP 2003 > > -- > Dimi. > > >

3 3

programmable shader research
by Simon Harvey 03 Jun '04

03 Jun '04

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 03 Jun '04

03 Jun '04

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 03 Jun '04

03 Jun '04

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 03 Jun '04

03 Jun '04

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