Re: dwarf.c small botch
"David Anderson" <[EMAIL PROTECTED]> wrote:
@@ -1095,7 +1095,7 @@ static unsigned dwarf2_map_register(int
switch (regno)
{
-case Wine_DW_no_register: FIXME("What the heck\n"); reg = 0; break;
+case Wine_DW_no_register: FIXME("What the heck map reg 0x%x\n",(unsigned
int)regno); reg = 0; break;
There is no need for a cast here.
/* FIXME: this is a dirty hack */
case Wine_DW_frame_register: reg = 0; break;
case 0: reg = CV_REG_EAX; break;
@@ -1394,8 +1394,16 @@ static struct symt* dwarf2_parse_subprog
subpgm.ctx = ctx;
subpgm.compiland = compiland;
-if (dwarf2_compute_location(ctx, di, DW_AT_frame_base, &subpgm.frame_offset,
&subpgm.frame_reg))
+if (dwarf2_compute_location(ctx, di, DW_AT_frame_base, &subpgm.frame_offset,
&subpgm.frame_reg)) {
TRACE("For %s got %ld/%d\n", name.u.string, subpgm.frame_offset,
subpgm.frame_reg);
+ if (subpgm.frame_reg == Wine_DW_no_register) {
+/* Likely a constant, meaning a location list offset.
+ We do not handle those yet. */
+ /*FIXME("need to handle location lists\n"); */
+ subpgm.frame_reg = 0;
+ subpgm.frame_offset = 0;
+ }
+}
Please follow the formatting style of the code you're changing: in placing
braces,
using spaces instead of tabs, formatting of the comments.
--
Dmitry.
Re: Propability that application X works in wine
On Wednesday 25 October 2006 08:11, Andreas Mohr wrote: > Hi, > > On Tue, Oct 24, 2006 at 11:05:10PM +0200, Stefan Dösinger wrote: > > Any ideas about that? > > One factor in the probability calculation would be the number of Google > hits for the application name (the more common, the better debugged it must > be), i.e. your popularity factor. > > Another one would be measuring the amount of APIs used by the program and > its libraries (use winedump?). > > Andreas Mohr I don't think this is very relevant. The probability of an application working would be related to the API "sets": touched by the application because wine doesn't have even coverage of all APIs, So the Probability that an applications API use will work in Wine depends on the product of the Probabilities of encountering an unimplemented call in each API and the criticality of that call - eg fatality of the missing functionality This could actually be computed for a crossection of application to give a general prediction, if you knew the frequency of use for each API call in a representative population of applications, and the completion status and criticality of all the cals in each API (or even just the % complete of the API - the problem being that the probability of a call being used isn't the same for all entry point in a given API) - By the way, in general this is called FMECA - Failure Modes, Effects and Criticality analysis - look up this topic for further ideas. It'd make a nice University student project. Bob
Re: Propability that application X works in wine
Hi, On Tue, Oct 24, 2006 at 11:05:10PM +0200, Stefan Dösinger wrote: > Any ideas about that? One factor in the probability calculation would be the number of Google hits for the application name (the more common, the better debugged it must be), i.e. your popularity factor. Another one would be measuring the amount of APIs used by the program and its libraries (use winedump?). Andreas Mohr
Re: use wine as screensaver for x
On Mo, 2006-10-23 at 11:11 -0700, Mike Hearn wrote:
> The way I did it was just to redirect the first created window, but again,
> it was hacky. Hopefully you can find a better way.
I dropped the explorer-idea and patched only winex11.drv:
After XSCREENSAVER_WINDOW was detected on DllMain/PROCESS_ATTACH,
I validated lpszClassName from CREATESTRUCTA (in X11DRV_CreateWindow),
set a new flag in x11drv_win_data and modified create_whole_window /
destroy_whole_window.
That was ok for fullscreen, but it need more work (and a wrapper) for
the Preview-Case ("wine screensavername.scr /p hWnd")
With "/s" for the preview in "xscrennsaver-demo", the graphic is to
large.
--
By by ... Detlef
Propability that application X works in wine
Hi, Beeing asked how it happenes that a comparably small application fails in wine while something bigger like office 2003 and half-life 2 works I thought how one could mathematically express that some application works in wine. There seem to be a few factors: * Some propability that some behavior Y causes a bug in wine. I assume that is fixed, perhaps a per-dll value, perhaps not * Of course the application size. How many different things does the app do. The bigger, the more likely it is that something of that fails. * People often complain that only popular apps work in wine, so the popularity of the app seems to be important. This manifests in the fact that bugs hit by popular apps are more likely to be fixed first. Ok, so how do these factors relate? Popularity seems to be the most important, but I am not sure how app size and the bug propability relate. Especially the bug propability would be interesting I think, as it might be some measure of the maturity of wine :-) Any ideas about that? Stefan pgp1SQB0Yj5E9.pgp Description: PGP signature
Re: [PATCH 5/5][resent] Implement MsgWaitForMultipleObjectsEx and initial Carbon event handling.
On 10/23/06, Mike McCormack <[EMAIL PROTECTED]> wrote: For the quartz driver, as it's not going to cause regressions inexisting code, you're probably better off submitting the entire thing inone big patch. Show us what the completed thing looks like, then we cangive you better feedback on it. If it's too big to post to wine-patches, try put it on a website, andsubmit a link to it.Julliard has reviewed it and decided he wanted it in small chunks. There is a bit of duplication with x11drv so he wants it developed a bit at a time so we can abstract the duplication away. -- Steven Edwards"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: advertising on winehq
On 10/24/06, Tom Wickline <[EMAIL PROTECTED]> wrote: Hmm, I wonder how many people mistakenly visit our front page looking for Wine ? winehq is the second result for "wine" in google. We can even increase this if we would be a bit more creative when thinking up new variable names in the code :-) I don't know the original reason, but adding the "hq" helps me a lot to narrow down the google results to the only wine I like. http://www.google.com/search?q=%22These+windows+are+sold%22
Re: advertising on winehq
On 10/24/06, Brian Vincent <[EMAIL PROTECTED]> wrote: On 10/24/06, Tom Wickline <[EMAIL PROTECTED]> wrote: > May I ask what you guys think about us starting to run some google ads > on winehq ? I think Google would probably display some nice advertisements for merlot. -Brian Hmm, I wonder how many people mistakenly visit our front page looking for Wine ? http://www.winepros.org/wine101/grape_profiles/merlot.htm Mogan David fan myself :-) Tom
Re: advertising on winehq
On 10/24/06, Tom Wickline <[EMAIL PROTECTED]> wrote: May I ask what you guys think about us starting to run some google ads on winehq ? I think Google would probably display some nice advertisements for merlot. -Brian
Re: WineD3D State management - going live(TM)
Can you describe what this would look like in detail I haven't thought it through in detail - just making sure you have. I think you're going in the right direction, as long as considering things other than render states in the design - won't bother you anymore, until I see some more of the code :) --- I've tracked down why wine deadlocks on my computer (miscompiled libX11 on Fedora Rawhide), so hopefully I can finish my texture/sampler testcases now, and vtf-related things [ and namespace cleanups ]. Actually VTF depend on what you're doing, and so do FBOs - they both require delayed application of certain states at draw time.
advertising on winehq
Hello, May I ask what you guys think about us starting to run some google ads on winehq ? With free software there are limited ways for a project to take in revenue and the two most common ways are by donations and running advertisements on a site. I don't in any way suggest we should become a flashing flash based site with obnoxious pop-ups and the likes. But I do believe we should however look into running small user friendly adverts from well respected companies such as google. And of course any money generated should go to the wpf to help support future wine confs. Comments? Tom
winhlp32 implementation
Hi, all! I intend to implement winhlp32 utility looks like native one (font size changing, GID and CNT files support, etc...). Please, share your opinion, has this idea any sense, or *.hlp died long ago and only few persons need it? Inspired by bug http://bugs.winehq.org/show_bug.cgi?id=5926 Thanks.
Re: comctl32: Hack for imagelist width greater than 2^16 (bug #3573)
Mike McCormack wrote: --- This hack is for bug #3573. I don't expect it to be applied to Wine, but perhaps it will give somebody some insight into solving the bug. WinRAR calls ImageList create and asks for an ImageList for 256 images, *expandable* to 2048. It doesn't actually use 2048 images: ImageList_Create (16 16 0x21 256 2048) 2048*256 is a bitmap wider than X.org wants, so it fails with a BadAlloc error. The correct solution is to rewrite the imagelist code to either 1) Allocate the bitmap on demand or 2) Store images in separate DIB sections. or 3) Store the images in an M/N x N format instead of an M x 1 format. -- Rob Shearman
Re: riched20: Make sure to use GlobalAlloc with GlobalFree.
Mike McCormack wrote: ret->ref = 1; ret->cur = 0; ret->fmtetc_cnt = fmtetc_cnt; -ret->fmtetc = HeapAlloc(GetProcessHeap(), 0, fmtetc_cnt*sizeof(FORMATETC)); +ret->fmtetc = GlobalAlloc(GMEM_ZEROINIT, fmtetc_cnt*sizeof(FORMATETC)); memcpy(ret->fmtetc, fmtetc, fmtetc_cnt*sizeof(FORMATETC)); *lplpformatetc = (LPENUMFORMATETC)ret; return S_OK; Why use GMEM_ZEROINIT when you initialise all of the memory straight after the GlobalAlloc call? -- Rob Shearman
Re: oleidl.idl must include windows.h and ole2.h if COM_NO_WINDOWS_H is not defined.
On Thu, 19 Oct 2006, Robert Shearman wrote: [...] > Is there any pattern to those that are missing it? I have not found it yet. > I would only expect to see the COM_NO_WINDOWS_H stuff in headers generated > from IDL files with at least one interface with the object keyword. Ah, you must know more than me as I had no particular expectations. There are some counter-examples: * Bits.h contains the COM_NO_WINDOWS section, but there is no object keyword in Bits.Idl. * Dimm.h contains no COM_NO_WINDOWS section, but there are object keywords in Dimm.Idl (but in a library section, maybe that makes a difference). Counter example to the "object keywords inside a 'library' don't count" hypothesis: SspsIdl.Idl. Maybe this has to do with what a given Idl file #imports? (which would make testing harder :-( ) Or maybe the headers that lack the COM_NO_WINDOWS section have been manually edited by MS after being generated by midl? -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95
Re: comctl32: Hack for imagelist width greater than 2^16 (bug #3573)
On Tue, Oct 24, 2006 at 06:11:30PM +0900, Mike McCormack wrote: > --- > > This hack is for bug #3573. I don't expect it to be applied to Wine, > but perhaps it will give somebody some insight into solving the bug. > > WinRAR calls ImageList create and asks for an ImageList for 256 images, > *expandable* to 2048. It doesn't actually use 2048 images: > > ImageList_Create (16 16 0x21 256 2048) > > 2048*256 is a bitmap wider than X.org wants, so it fails with a BadAlloc > error. Actually 2048*16 is too wide. > The correct solution is to rewrite the imagelist code to either > > 1) Allocate the bitmap on demand > > or > > 2) Store images in separate DIB sections. 3) Allocate in a 4 image deep band like Windows does. Ciao, Marcus
Re: Extra info on d3dsurface crash
Am Montag 23 Oktober 2006 22:46 schrieb Robert Lunnon: > I think you are right about that, an accurate diagnostic would be helpful > and prompt someone to write the decompression code, if it's not hard I > could do that.. > > This application used to work before the d3d stuff went in (perhaps a > fall-back) If I sent you a copy of the app could you test under linux to > see if the behaviour is the same (I develop the Solaris version). It is certainly not hard, and the old ddraw code had decompression support. The issue is more a legal one. VIA holds a patent on s3tc compression. There is a s3tc compression/decompression library available(http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html), but the legal situation of using it is difficult. The old ddraw code used that lib, if available, to work with s3tc surfaces. You can basically just copypaste the code from old ddraw(wine 0.9.15, dlls/ddraw/surface_dib.c I think) and see if that helps. A different way would be to use opengl to upload the compressed texture and read it back uncompressed, but this is tricky from a wined3d point of view because surface_gdi.c is supposed to work completely without opengl. pgpwAvfD4cW2Z.pgp Description: PGP signature
