February 2004 - Wine-Devel - list.winehq.org

programs/winedbg/elf.c breaks non-Linux platforms

by Gerald Pfeifer

Hi, I'm afraid the following patch which added programs/winedbg/elf.c date: 2004/02/03 00:14:12; author: julliard; state: Exp; Eric Pouech <pouech-eric(a)wanadoo.fr> - now detecting Dwarf debug information in ELF modules (but don't load it) - separated module management (pe.c, elf.c) from debug information management (stabs.c, msc.c) - worked around new wine-pthread and wine-kthread loaders (no longer use "wine" as default loader) - better convergence of gdb-proxy and winedbg for ELF handling - fixed ELF link-map walking - now using all loaded shared libs - (with the help of Robert Shearman) - added a bit of const correctness breaks building Wine on non-Linux platforms. For example, on FreeBSD 4.9 I'm seeing: elf.c: In function `DEBUG_ProcessElfFile': elf.c:344: error: `DT_NUM' undeclared (first use in this function) elf.c:344: error: (Each undeclared identifier is reported only once elf.c:344: error: for each function it appears in.) elf.c:344: error: `DT_PROCNUM' undeclared (first use in this function) elf.c:344: error: `DT_EXTRANUM' undeclared (first use in this function) elf.c:345: error: `DT_LOOS' undeclared (first use in this function) elf.c:345: error: `DT_HIOS' undeclared (first use in this function) elf.c:346: error: `DT_LOPROC' undeclared (first use in this function) elf.c:346: error: `DT_HIPROC' undeclared (first use in this function) Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

Feb. 3, 2004

Re: OLEPictureImpl_Load: fix for headerless pictures

by Kirill Smelkov

On Tue, 3 Feb 2004, Fabian Cenedese wrote: > > >> I don't think that this is correct. If header[1] is 0 then it means that there is no picture at > >> all, and not a picture without header (me thinks). When trying to start a program that uses > >> the SSTab from TabCtl32.ocx without having assigned icons to the tabs it fails because > >> wine tries to create icons that aren't in the stream. So there's no point in continuing and trying > >> to read data from the stream. I could only make it work when I jump out of this function > >> without doing anything if header[1] is 0. That may be wrong too but this patch doesn't > >> solve it either. > > > >In my case there are lots of *.bmp (with picture) with exactly same header > >i mentioned. Thus header[1]==0 doesnt imply 'there is no picture at all' > > > >This pictures came in ole storage taken from a real win32 app, and loading > >them on windows works correctly. > > Do you have VB6? Can you create a testprogram? If not then I can send you one. > Just create an empty form and place the SSTab on it (the one from tab control, > not the one in the standard palette). I don't have VB. In fact i ether dont have VC and windows installed at all here. If you have an winelib based example, let's try get it working. > This fails on on my computer and I don't > know how wine could detect if it's a headerless picture or no picture at all > if they look the same (so far). Maybe check header[0] to be real .bmp or .gif magic and header[1] for zero? -- Kirill.

Feb. 3, 2004

Re: OLEPictureImpl_Load: fix for headerless pictures

by Kirill Smelkov

On Tue, 3 Feb 2004, Fabian Cenedese wrote: > > >Hi, > >In my case headerless bitmaps have > >{ 0x42, 0x4d, 0x9c, 0xbd, 0x00, 0x00, 0x00, 0x00 } first 8 bytes. > > > >So, when last four are equal to zero its 'no header' case. > > > >ChangeLog: > > OLEPictureImpl_Load: fix for headerless pictures > > > >Index: dlls/oleaut32/olepicture.c > >=================================================================== > >RCS file: /home/wine/wine/dlls/oleaut32/olepicture.c,v > >retrieving revision 1.30 > >diff -u -r1.30 olepicture.c > >--- dlls/oleaut32/olepicture.c 5 Sep 2003 23:08:33 -0000 1.30 > >+++ dlls/oleaut32/olepicture.c 1 Feb 2004 12:35:41 -0000 > >@@ -875,7 +875,7 @@ > > FIXME("Failure while reading picture header (hr is %lx, nread is %ld).\n",hr,xread); > > return hr; > > } > >- if (header[1] > statstg.cbSize.QuadPart) {/* Incorrect header, assume none. */ > >+ if (header[1] > statstg.cbSize.QuadPart || (header[1]==0)) {/* Incorrect header, assume none. */ > > xread = 8; > > xbuf = This->data = HeapAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,statstg.cbSize.QuadPart); > > memcpy(xbuf,&header,8); > > I don't think that this is correct. If header[1] is 0 then it means that there is no picture at > all, and not a picture without header (me thinks). When trying to start a program that uses > the SSTab from TabCtl32.ocx without having assigned icons to the tabs it fails because > wine tries to create icons that aren't in the stream. So there's no point in continuing and trying > to read data from the stream. I could only make it work when I jump out of this function > without doing anything if header[1] is 0. That may be wrong too but this patch doesn't > solve it either. In my case there are lots of *.bmp (with picture) with exactly same header i mentioned. Thus header[1]==0 doesnt imply 'there is no picture at all' This pictures came in ole storage taken from a real win32 app, and loading them on windows works correctly. -- Kirill.

Feb. 3, 2004

Re: OLEPictureImpl_Load: fix for headerless pictures

by Fabian Cenedese

>> >> This fails on on my computer and I don't >> >> know how wine could detect if it's a headerless picture or no picture at all >> >> if they look the same (so far). >> > >> >Maybe check header[0] to be real .bmp or .gif magic and header[1] for >> >zero? >> >> I couldn't see a difference, always 0x746c in the first entry. > >Then what type of picture it is? > >0x4947 GIF >0xd8ff JPEG >0x4d42 BMP >0x0000 ICON >0x746c ??? Well, as I didn't use any pictures I don't know what it's supposed to be. Might as well be "NoPic" :) But I have also seen this marker where the second field was not zero. >Have you seen something like "Unknown magic, blah-blah-blah..."? It depends. Without your patch (where [0]=746c, and [1]=0) : trace:ole:OLEPictureImpl_Load (0x40383880,0x414de29c) fixme:ole:OLEPictureImpl_Load icon.idReserved=0 fixme:ole:OLEPictureImpl_Load icon.idType=0 fixme:ole:OLEPictureImpl_Load icon.idCount=0 fixme:ole:OLEPictureImpl_Load [0] width 0 fixme:ole:OLEPictureImpl_Load [0] height 0 fixme:ole:OLEPictureImpl_Load [0] bColorCount 0 fixme:ole:OLEPictureImpl_Load [0] bReserved 0 fixme:ole:OLEPictureImpl_Load [0] xHotspot 0 fixme:ole:OLEPictureImpl_Load [0] yHotspot 0 fixme:ole:OLEPictureImpl_Load [0] dwDIBSize 0 fixme:ole:OLEPictureImpl_Load [0] dwDIBOffset 0 fixme:ole:OLEPictureImpl_Load CreateIcon failed. (obviously when all data are 0) trace:ole:OLEPictureImpl_Release (0x40383880)->(ref=2) trace:ole:OLEPictureImpl_Release (0x40382ec8)->(ref=1) trace:ole:OLEPictureImpl_Destroy (0x40382ec8) trace:ole:OLEPictureImpl_Release (0x40383880)->(ref=1) trace:ole:OLEPictureImpl_Destroy (0x40383880) fixme:ole:OLEPictureImpl_Destroy Unsupported type 0 - unable to delete trace:ole:OLEPictureImpl_Release (0x40380a70)->(ref=1) trace:ole:OLEPictureImpl_Destroy (0x40380a70) trace:ole:OLEFontImpl_ReleaseHfont (0x4037f648)->(0xd82) (lock=0) trace:ole:OLEPictureImpl_Release (0x4037f7a8)->(ref=1) trace:ole:OLEPictureImpl_Destroy (0x4037f7a8) With your patch (already earlier with [0]=756c, [1]=...): fixme:ole:OLEPictureImpl_Load Could only read 109 of 2763 bytes in no-header case? fixme:ole:OLEPictureImpl_Load Unknown magic 746c, 109 read bytes: 6c 74 00 00 00 00 00 00 6c 74 00 00 00 00 00 00 00 00 01 00 00 00 0a 00 54 00 61 00 62 00 20 00 31 00 01 00 00 00 04 52 e3 0b 91 8f ce 11 9d e3 00 aa 00 4b b8 51 6c 74 00 00 00 00 00 00 00 00 00 00 00 00 0a 00 54 00 61 00 62 00 20 00 32 00 01 00 00 00 04 52 e3 0b 91 8f ce 11 9d e3 00 aa 00 4b b8 51 6c 74 00 00 00 00 00 00 00 00 00 00 00 00 ff 02 04 Maybe this isn't even part of a picture and we shouldn't be reading this. How does it know that a picture is coming? Perhaps we shouldn't even enter OLEPictureImpl_Load if there is no picture at all. Thanks bye Fabi

Feb. 3, 2004

Re: Sourceforge WIne RPMs and Yum

by Dwayne Bailey

Hi, Are there any yum experts here? I thought it would be a good idea to get a yum repository established for the Wine RPMs held at sourceforge. I for one would love to have the latest build of wine installed as soon as RPMs are available on Sourceforge. yum-arch seems to be the command to create the repository headers but I'm not sure how you would manage this with the round robbin sourceforge downloads. I think some other sf project have managed this. Anyone out their who can help? Dimitrie O. Paun wrote: >On February 3, 2004 04:42 am, you wrote: > > >>I was wondering if it would be possible to create yum repositories >>of the Sourceforge RPMs certainly for use with Fedora. >> >> > >It sounds like a really good idea, but I know little about the topic, >as I'm not yet running Fedora. You may want to post a call for >volunteers on wine-devel(a)winehq.org, maybe someone has the know-how >and steps forward... > > > -- Kind regards Dwayne Bailey dwayne(a)translate.org.za +27-21-448 7827 / 9265 (work) +27-21-448 9574 (fax) +27-83-443 7114 (cell) "An English-only, or even an English-mainly, policy necessarily condemns most people, and thus the country as a whole, to a permanent state of mediocrity, since people are unable to be spontaneous, creative and self-confident if they cannot use their first language" Dr Neville Alexander - 'Where English can Serve but not Empower.' Translate.org.za - Opensource software for all South Africans A project of the Zuza Software Foundation Zuza - given freely, get as a gift, obtained freely

Feb. 3, 2004

Re: Wine 0.9 TODO

by Dimitrie O. Paun

On February 3, 2004 02:56 am, Lars Segerlund wrote: > I am curious about 'testing daemon to run as windows service' [I'm Cc:-ing wine-devel, other may be interested in this as well] This TODO item has nothing to do with running services under Wine. What this is instead is a real Win32 service for Windows. The purpose of this service is to help us automate the running of our conformance test suite under Windows. It's operation should be very simple: once installed, it has to poll (say every 1h) a location on winehq.org to determine when new tests are available. When they are, it has to download one executable (winetest.exe), and run it (winetest.exe -b). That's it. This way, people that want to help us test, can simply install this service, and go by their business. Needless to say, we need a volunteer for this... No Unix experience required, this is purely a Win32 little app. Nice way to get started :) -- Dimi.

Feb. 3, 2004

buffer too small for currency

by Fabian Cenedese

Hi I get this warning when I try to start a basic program. This comes from the function VARIANT_GetLocalisedNumberChars. I added some printfs and found that my currency is apparently "SFr.", so 4 chars plus zero which is too much for the 4 char buffer. Strange though that on the command line it looks differently: locale -k LC_MONETARY int_curr_symbol="CHF " currency_symbol="Fr." mon_decimal_point="." mon_thousands_sep=" " mon_grouping=3;3 ... Anyway, I thought I increase this buffer. But then the string gets stored in two separate variables (each one char) in the VARIANT_NUMBER_CHARS struct. Is there a reason that this is not a string? Why only two chars? Thanks bye Fabi

Feb. 3, 2004

Re: OLEPictureImpl_Load: fix for headerless pictures

by Fabian Cenedese

>> >In my case there are lots of *.bmp (with picture) with exactly same header >> >i mentioned. Thus header[1]==0 doesnt imply 'there is no picture at all' >> > >> >This pictures came in ole storage taken from a real win32 app, and loading >> >them on windows works correctly. >> >> Do you have VB6? Can you create a testprogram? If not then I can send you one. >> Just create an empty form and place the SSTab on it (the one from tab control, >> not the one in the standard palette). >I don't have VB. In fact i ether dont have VC and windows installed at all >here. > >If you have an winelib based example, let's try get it working. It's not a winelib app but I can send you the exe and ocx off the list. >> This fails on on my computer and I don't >> know how wine could detect if it's a headerless picture or no picture at all >> if they look the same (so far). > >Maybe check header[0] to be real .bmp or .gif magic and header[1] for >zero? I couldn't see a difference, always 0x746c in the first entry. bye Fabi

Feb. 3, 2004

Re: OLEPictureImpl_Load: fix for headerless pictures

by Fabian Cenedese

>> I don't think that this is correct. If header[1] is 0 then it means that there is no picture at >> all, and not a picture without header (me thinks). When trying to start a program that uses >> the SSTab from TabCtl32.ocx without having assigned icons to the tabs it fails because >> wine tries to create icons that aren't in the stream. So there's no point in continuing and trying >> to read data from the stream. I could only make it work when I jump out of this function >> without doing anything if header[1] is 0. That may be wrong too but this patch doesn't >> solve it either. > >In my case there are lots of *.bmp (with picture) with exactly same header >i mentioned. Thus header[1]==0 doesnt imply 'there is no picture at all' > >This pictures came in ole storage taken from a real win32 app, and loading >them on windows works correctly. Do you have VB6? Can you create a testprogram? If not then I can send you one. Just create an empty form and place the SSTab on it (the one from tab control, not the one in the standard palette). This fails on on my computer and I don't know how wine could detect if it's a headerless picture or no picture at all if they look the same (so far). Thanks bye Fabi

Feb. 3, 2004

Re: OLEPictureImpl_Load: fix for headerless pictures

by Fabian Cenedese

>Hi, >In my case headerless bitmaps have >{ 0x42, 0x4d, 0x9c, 0xbd, 0x00, 0x00, 0x00, 0x00 } first 8 bytes. > >So, when last four are equal to zero its 'no header' case. > >ChangeLog: > OLEPictureImpl_Load: fix for headerless pictures > >Index: dlls/oleaut32/olepicture.c >=================================================================== >RCS file: /home/wine/wine/dlls/oleaut32/olepicture.c,v >retrieving revision 1.30 >diff -u -r1.30 olepicture.c >--- dlls/oleaut32/olepicture.c 5 Sep 2003 23:08:33 -0000 1.30 >+++ dlls/oleaut32/olepicture.c 1 Feb 2004 12:35:41 -0000 >@@ -875,7 +875,7 @@ > FIXME("Failure while reading picture header (hr is %lx, nread is %ld).\n",hr,xread); > return hr; > } >- if (header[1] > statstg.cbSize.QuadPart) {/* Incorrect header, assume none. */ >+ if (header[1] > statstg.cbSize.QuadPart || (header[1]==0)) {/* Incorrect header, assume none. */ > xread = 8; > xbuf = This->data = HeapAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,statstg.cbSize.QuadPart); > memcpy(xbuf,&header,8); I don't think that this is correct. If header[1] is 0 then it means that there is no picture at all, and not a picture without header (me thinks). When trying to start a program that uses the SSTab from TabCtl32.ocx without having assigned icons to the tabs it fails because wine tries to create icons that aren't in the stream. So there's no point in continuing and trying to read data from the stream. I could only make it work when I jump out of this function without doing anything if header[1] is 0. That may be wrong too but this patch doesn't solve it either. Described here: http://www.winehq.org/hypermail/wine-devel/2004/01/0968.html bye Fabi

Feb. 3, 2004