May 2009 - Wine-devel - list.winehq.org

Re: comdlg32: fix romanian translation
by Michael Stefaniuc 04 May '09

04 May '09

André Hentschel wrote: > suggested by Dimitriu Petru > --- > dlls/comdlg32/cdlg_Ro.rc | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) This patch is wrong. The Romanian language uses "ț" aka "t with comma below accent" and not "ţ" which is "t with cedilla". bye michael

1 0

GUI debugging
by Benoit SCHWINDEN 04 May '09

04 May '09

Hello, I am trying to make a very special application working with Wine 1.1.20 (Loris, from Ever Ezida, a library management software). Almost everything is functionnal, but there is a little graphical bug with some texfields. Also, I would like to know if there are some ways to debug a GUI, especially a way to know which library or DLL is called to display a part of this GUI (ie know what DLL is used to display my faulties text fields). Thanks a lot by advance. Best regards, Benoit. -- Benoit SCHWINDEN Direction Informatique Groupe GNU/Linux Université de Strasbourg 03 90 24 12 46

1 0

Giving up for now
by Joel Holdsworth 04 May '09

04 May '09

Hi All, I've hit a bit of a wall with alpha blended icons. CreateIcon is working fine for icon creation, but ExtractIcon and LoadIconFromResource etc. are all proving more of a problem. All of these use various GDI DIB functions to coerce the icon bitmap to the correct colour depth and size. The problem is that preserving the alpha channel through these DIB functions seems to be impossible because they go via X11, so until the dib engine is merged (after hell freezes over) I'm not sure I can go much further. Joel

4 10

Re: Office 2007 MSI Crash - Null dereference @ MsiViewExecute
by Mike Kaplinskiy 04 May '09

04 May '09

On Sun, May 3, 2009 at 10:36 PM, James Hawkins <truiken(a)gmail.com> wrote: > On Sun, May 3, 2009 at 1:52 PM, Mike Kaplinskiy > <mike.kaplinskiy(a)gmail.com> wrote: >> On Thu, Apr 30, 2009 at 1:08 PM, James Hawkins <truiken(a)gmail.com> wrote: >>> On Thu, Apr 30, 2009 at 4:03 AM, Austin English <austinenglish(a)gmail.com> wrote: >>>> On Tue, Apr 28, 2009 at 9:27 PM, Mike Kaplinskiy >>>> <mike.kaplinskiy(a)gmail.com> wrote: >>>>> I was looking at the trace of the crash from bug 17600, and it looks like >>>>> a custom action is calling MsiViewExecute with a null hRec. >>>>> >>>>> I (sadly) don't know much about the wine MSI architecture, but the >>>>> msiobj_lock on line 484 should fail since rec will never be fetched >>>>> (null). I think the intention was to make it query->hdr (as it is >>>>> released later). >>>> >>>> A testcase for it would show if you're right or wrong ;-). >>>> >>> >>> Not really. If you grep through the msi tests, you'll see that we >>> call MsiViewExecute with NULL hRec all over the place. That doesn't >>> mean there isn't a bug, just saying. >>> >>> -- >>> James Hawkins >>> >> >> So I got a little time to look into this, and was completely blown >> away. Apparently doing >> >> TRACE("dereferencing 0?=%p\n", (void *) &(((MSIRECORD *) NULL)->hdr)); >> >> works, since nothing ever gets dereferenced. I will post a patch for >> this small nit. >> >> On a slightly different note, I have traced the problem in office 2007 >> to the patch by James, and in particular to INSERT_execute. The row >> index gets set to 0 if the primary key is null (which is what office >> install is doing), but if the insert is temporary TABLE_insert assumes >> that row >= tv->table->row_count, and subtracts from the row index, >> putting us in the negatives (or high positives due to uint). >> >> I have a patch for this, but I don't know how to make a testcase (all >> I know is office installs), so would anyone mind pointing me to >> somewhere that explains msi temporary inserts? >> >> And should I post the patch up on wine-patches to get it critiqued? >> (sorry, first time) >> > > I'll take a look at your patch. No offense intended, but it's > probably not correct. The problem is a beast and deeply rooted in the > way we store temporary rows in the DB. I have a huge test patch for > it, and I had a fix, but my linux HD got fragged (bummer). > > -- > James Hawkins > (Sorry, forgot to forward to the list) Thanks James. I'm not gonna post it on the patches list quiet yet then. I checked that the msi tests pass with the patch as well. Mike.

1 0

Office 2007 MSI Crash - Null dereference @ MsiViewExecute
by Mike Kaplinskiy 04 May '09

04 May '09

I was looking at the trace of the crash from bug 17600, and it looks like a custom action is calling MsiViewExecute with a null hRec. I (sadly) don't know much about the wine MSI architecture, but the msiobj_lock on line 484 should fail since rec will never be fetched (null). I think the intention was to make it query->hdr (as it is released later). Sorry if I'm dead wrong - just my 2c

3 5

Re: Severity levels
by Ken Sharp 03 May '09

03 May '09

IneedAname wrote: > On Sun, 03 May 2009 18:10:03 +0100 > Ken Sharp <kennybobs(a)o2.co.uk> wrote: > >> That would be the "Show Apps affected by this bug" link then. >> http://appdb.winehq.org/viewbugs.php?bug_id=16281 > > Thanks I missed that so how but my first point still stands. > Not really. 16281 certainly isn't a major loss of functionality, no matter how many bugs are attached to it.

1 0

Re: user32: combine horizontal and vertical window scroll bar info in a single structure.
by Alexandre Julliard 03 May '09

03 May '09

Rein Klazes <wijn(a)online.nl> writes: > - if (!infoPtr && alloc) > + if (!infoPtr && ( alloc || (wndPtr->dwStyle & (WS_VSCROLL | WS_HSCROLL)))) > { This bit doesn't look right, and defeats the purpose of the alloc flag. It would need some more test cases. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: wine-devel Digest, Vol 46, Issue 10
by chris ahrendt 03 May '09

03 May '09

wine-devel-request(a)winehq.org wrote: > _______________________________________________ > wine-devel mailing list - wine-devel(a)winehq.org > http://www.winehq.org/mailman/listinfo/wine-devel > > > ------------------------------------------------------------------------ > > Subject: > Re: RFC on Base Wine Config > From: > Kai Blin <kai.blin(a)gmail.com> > Date: > Sun, 3 May 2009 09:04:13 +0200 > To: > wine-devel(a)winehq.org > > To: > wine-devel(a)winehq.org > > > On Sunday 03 May 2009 07:07:35 Ben Klein wrote: > >> 2009/5/3 chris ahrendt <celticht32(a)yahoo.com>: >> > > Replying to Ben's email as I didn't get Chris' email Ben replied to. > I would also like to note that I don't appreciate the tone both of these > emails are taking in the end. Please try to be civil. > > That being said, let me get to the technical part. > > >>> I guess I am not being completely clear somewhat.... >>> If I am in windows and go into explorer... >>> >> We've been through this before. Wine is not Windows. In Wine, the >> drive has to be mapped in dosdevices. >> >>> go to a network drive. I do >>> not nescisarily have to map that drive in order to run an application >>> (so long as the DLLS it needs, if any, are not just on that drive). I >>> can click the application >>> and it runs. I realise this may be a fundamental difference between unix >>> and windows but still they should theoretically run the same. >>> > > The important part here is that your local drives are local drives. Don't > confuse the Wine drive mappings with network drive mappings in Windows. Think > about a Wine drive mapping like plugging a new hdd into your box. > > >> But you're NOT running the test from a network drive, are you? And >> even if you were, you'd need some way to inform Wine that it's there, >> which would be to map it to a drive. Does Wine even support >> Windows-style shares? >> > > Nope. We could, but then you'd have to create a Samba share to allow us to use > the directory. I'm pretty sure a wine drive mapping is easier and faster. > > >>> Also from >>> a command line I can do (I think if I am remembering correctly (been >>> doing to much z work lately) ) //server/directory/app.exe and it will >>> retrieve and run the app... (I think) >>> > > That's a bit besides the point, as this is still a valid UNC path. Now imagine > I've got a USB hdd with my app on it, and that's usually connected at U:, > with my app being at U:\test\app.exe. Now the logic in Windows mapping my USB > drive to U: is just what the wine dosdevice mapping is like. If I now tell > windows to remove the USB device, my desktop link to U:\test\app.exe is not > going to work anymore. > > >> This message appears in your bug report: >> >>> Warning: could not find DOS drive for current working directory >>> '/home/cahrendt/wine-git/dlls/inetmib1/tests', starting in the Windows >>> directory. >>> > > Here my analogy would be a bit stretched, as in that you'd still manage to be > on the USB drive while it's already been disconnected. But basically you're > trying to run a program that's on a drive not connected to your wine "box". > > Cheers, > Kai > > > Thanks Kai, This is the kind of dialog I was looking for in the RFC. This makes sense. In a way with you are in a seperate 'region' and do not have access to that regions resources unless you map it. Even though wine is not a emulator it is essentially a VM running in userspace on the box that you need to allocate some resources to. (not so much like solaris 10 or zVM's where you can set up resources for everything). Ok clear now. Chris

1 0

Limit of todo_wine ?
by Massimo Del Fedele 03 May '09

03 May '09

Today writing a testcase I found a "problem" on todo_wine construct. In short : void first_test_part() { ok(test1(), "failed\n"); } void second_test_part() { ok(test2(), "failed\n"); } todo_wine { first_test_part(); second_test_part(); } this "fails" (i.e. is marked as passing inside todo_wine block) if first_test_part() passes, which is not what wished; in this case the test should be considered passing if BOTH first and second part passes, and failed otherwise. The problem arose on bitmap creation test (gdiplus) on which the testcase should check for creation success AND bitmap internal consiscency. My example is short, but in my case there's a single function used to test many kind of bitmaps; that's impossible to do with todo_wine actual construct. It could be obviously separated into many functions, each enclosed on its own todo_wine, but this would vanify the "single test function for many bitmaps types" way. Max

2 2

Re: [shell32] stub for ExtractVersionResource16W
by Dmitry Timoshkov 03 May '09

03 May '09

"Stefan Leichter" <Stefan.Leichter(a)camline.com> wrote: > +/*********************************************************************** > + * ExtractVersionResource16W (SHELL32.@) > + */ > +BOOL WINAPI ExtractVersionResource16W(LPWSTR s, DWORD d) { > + FIXME("(%s %x) stub!\n", debugstr_w(s), d); > + return FALSE; > +} Please follow the braces placement style of the file. Also you might be interested that according to http://www.geoffchappell.com/viewer.htm?doc=studies/windows/shell/shell32/h… ExtractVersionResource16W is discontinued starting from Windows Vista. -- Dmitry.

3 3