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

Support for IDvdInfo2::GetDiscID
by James Courtier-Dutton 25 Mar '05

25 Mar '05

The Windows api method uses the function call IDvdInfo2::GetDiscID http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c… This returns a unique 64bit ID for a DVD. Has anyone found out what exactly it does to create this 64bit ID. It would be nice to get linux DVD players to be able to use the same method. Cheers James

2 2

text edit box not painting text ( on form startup )
by Doug Herbert 09 Mar '05

09 Mar '05

( I have posted a similiar question in wine-users, don't flame me for doing so, just thinking about this some more, perhaps it may be more a developer question ) Ok, I have a windows app, that runs under wine fine - not quite. This app has a form, with many text field edit boxes on. Quite often these edit boxes already have text values, ie. they are not empty - there is a database behind the form. Anyway, the form shows on the screen, but the text within the edit fields is invisible, until you activate each edit box component. When you leave one edit box to the next, the text remains visible. It seems like the repainting is not working, on initial startup of the form. As a way to debug this database app ( I don't have the source code for it ) I wrote a real basic form app in Visual Studio, with two edit boxes, with data in each. Now this basic app shows the text values immediately on startup. So there must be something different that the database app is not doing. I then ran wine using 'wine --debugmsg +edit programname' for both app's. I see both logging 'Creating ANSI edit control, style = xxxxx' but the style reference is different between apps - I am not sure if this the cause or not. The problem app reports style = 54011104 and the basic app shows style = 50010080. Can somebody explain what this style reference means and how do I force an app to use a certain style of edit box ? What other wine class debugmsg types should I use to narrow down the source of this problem ? Is there anyway I can check to see how the database app is repainting text within the text edit components ? Regards Doug Herbert. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

3 4

Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]
by Mike Hearn 17 Jan '05

17 Jan '05

>>Well, apparently we don't use sched_yield, so the problem must >>> lie somewhere else. Maybe Con can help us out here? Alexandre says he >>> doesn't know what the issue is either and somebody needs to investigate. I >>> guess we do need to concern ourselves over the details :) > > > Interesting. Probably the most valuable information is that it seems to > work fine if we artificially limit the threads to exactly the same > timeslice _or_ we put them at such a low priority that they are forced > to be guaranteed to round robin one task at a time. This is the way 2.4 > used to work which is why with the new 2.6 schedulers which do far more > out-of-order rescheduling some applications have a problem; particularly > under load. I suspect it's actually the latter issue. Locking between > threads should prevent that being a problem, though. You already > mentioned that you dont use sched_yield() and I couldn't even begin to > look at the wine code myself so perhaps you know something more. Hi Con, One thought that occurred to me, and this is just a random theory, is that maybe the issue is not with the Wine code but the Win32 code run on top of it. Do you know how 2.6 scheduling compares with 2.4 and Windows (NT) scheduling? Could it be that some apps are written to expect Windows-style scheduling and fail to work if they don't get it? In case you hadn't noticed, I'm afraid I only have first-year CS knowledge of scheduling :/ thanks -mike

17 43

working together on stdole.tlb and a end to dcom9x
by Steven Edwards 28 Nov '04

28 Nov '04

Hello, Once again cross-posting because I would like to see if this is something we can work together on. What is left to do for us to be able to build and have a working implementation of stdole.tlb or any other type libs? I ask because it seems Wines DCOM implementaton is almost good enough for most apps except for this file and ReactOS is quickly getting to the point that it can run most of the same stuff Wine can without DCOM9x installed. Thanks Steven _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

7 14

dlls/commdlg/fontdlg.c regression
by Gerald Pfeifer 13 Nov '04

13 Nov '04

The following change to dlls/commdlg/fontdlg.c revision 1.70 date: 2004/08/14 00:42:35; author: julliard; state: Exp; lines: +2 -5 Jacek Caban <jack(a)itma.pwr.wroc.pl> Fix a bug in passing parameters to CFn_WMInitDialog and CFn_WMCommand in FormatCharDlgProcW. causes the following warning with GCC 3.3.2 on FreeBSD 4.10: fontdlg.c:1161: warning: passing arg 4 of `CFn_WMCommand' from incompatible pointer type Would you mind fixing this? Thanks, Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

2 3

Re: Wine on FreeBSD current
by Gerald Pfeifer 30 Oct '04

30 Oct '04

>> I'm just wondering if it is supposed to work as well as FreeBSD stable. Right now, Wine doesn't work at all on FreeBSD -STABLE: wine: failed to initialize: /swtest/wine/dlls/ntdll.dll.so: mmap of entire address space failed: Cannot allocate memory and before that I used to see deadlocks upon startup of non-trivial applications (such as Forte Agent, both 16bit and 32bit flavors). I believe there are also signficant threadings issues on -CURRENT, so overall Wine is hardly, if at all, usable on any version of FreeBSD I have access to, even though I'm still working to keep it at least compilable on FreeBSD 4.9 and 5.2/5.3. Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

6 13

Other W->A crosscalls
by Vincent Béron 15 Sep '04

15 Sep '04

I played a bit with smatch and Wine (after reading http://people.redhat.com/mstefani/wine/smatch/) to try to get over what I mentionned in my last email (regarding winapi_check and cross-calls in parenthesis). I attach the smatch script to generate the results I have. It's still not perfect (the listview.c references are wrong, for example), but as it's tied to gcc it can detect some calls which otherwise would not be caught. For example, the calls to GetWindowLongA in header.c are in a macro. Not all of them are bugs: caution is needed when checking, although reducing the number of false positive would likely be welcome (either by modifying the script or patches). Vincent

4 6

W->A calls
by Joris Huizer 11 Sep '04

11 Sep '04

Hello, By accident, I removed the emails of the thread I started, but I'll look it up if necessary; I found this old wine issue of some time ago.. I think the patch it has there could be helpfull http://winehq.org/?issue=229#About%20Converting%20W-%3EA%20Calls However, I don't know how to make simple tests.. as I'd really need to test wether the code I write works, and works properly :p How do I write tests for that? I'm running linux (in practice, I never boot into windows) so how should I do this (testing without windows environment)? How are tests supposed to run? I hope you can give some clues on that; I found there are many W->A calls in dlls/winmm/winmm.c (according to the janitorial page) so I might start there (hoping not all of them are so tricky ;) ) Thanks for suggestions on this, Joris

7 9

Simple bugzilla question
by Ann and Jason Edmeades 08 Sep '04

08 Sep '04

Hiya, I've just set up a temporary Linux system to try to get back into doing some wine development following a break and thought I'd start by looking at some bugzilla bugs for now. I'm sure there used to be a page which showed the lifespan of a bug but for the life of me I cant see it. My understanding is I accept it and assign to myself, then fix it, then what... Do I put the bug in fixed state and submit the patch or leave that change to the raised? Jason

2 1

More winecfg todos
by Mike Hearn 07 Sep '04

07 Sep '04

On Thu, 29 Jul 2004 23:19:11 -0500, Alexandre Julliard wrote: > Log message: > James Hawkins <truiken(a)gmail.com> > Under the Drives tab, remove the 'Windows Drive' section. You probably want to increase the size of the drive mappings list so it fills the tab, currently there is just a lot of empty space at the top of the pane now you removed the old stuff. Also we should kill the autodetect button. This is done by wineprefixcreate these days, or should be. Other things are: - Drive editing seems broken. The list box only updates the second time I hit edit. err:winecfg:applyDriveChanges unable to set volume label for devicename of 'H:\', label of '' - Browse in the "Add/Edit drive" dialog is a WRITEME - Build system isn't right: I did a cvs update but the res files weren't recreated properly. I had to do a make clean to get the gui updates. - "Add Application" has poor usability: we always use a file browser dialog box even though the most common use case is just "foo.exe", ie the user knows the name and doesn't care about the location. Worse we start in the c:\windows\desktop folder for some reason, meaning users might accidentally select a .lnk file! Ditto for Libraries tab. - The Add/Remove application buttons are *way* too big! - Obviously, once audio autodetection has been moved into the drivers we need to kill the audio tab. - Libraries tab just has generally poor usability, actually. The first item in the radio group is "Builtin" meaning that's the one users are most likely to select, it should be "builtin, native" followed by "native, builtin" - We ask the user to understand a magic * symbol to set the default - what is up with that? - There are no helpful default entries in the drop down box for setting a DLL override, and when you add one the tree does not expand so to actually *set* it you have to expand the tree then select the new override. - We have way too many (eg, more than zero) tree controls in this app. - Drive mappings list is really unclear, there's no separation between the "Drive X:" label and the unix path its mapped to. Basically I'd recommend reading the GNOME HIG: http://developer.gnome.org/projects/gup/hig/ it's a very informative read. Obviously we have to use Win32 UI conventions at least at first, but there's a lot of generically good advice there. Well worth reading for anybody who is going to work on winecfg. thanks -mike

4 4