Anyone know anything about this function? I stubbed
it to get around an occasional crash in native common
controls, but I'm not positive the function
signature's correct.
--Juan
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
>> >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
>> 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
>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
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
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.
After a slippery drive home (12 stressful hours from Minneapolis ->
Kansas City, rather than the six it took me to get there on Friday), I
finally have time to report a bit on WineConf.
First of all, I'd like to thank Codeweavers on behalf of those of us
from ReactOS that attended the conference. It was really run well, with
ample free food (always a requirement). I didn't even mind -5F as much
as I thought!
There were about 35 Wine and ReactOS hackers there, and two days worth
of presentations. I started getting serious questions about ReactOS the
instant people figured out who I was. There was about a 50/50 split
between people wanting to know what it was and people wondering why we
are bothering to do this. There were a lot of interesting (and
passionate) conversations about the role of Linux on the desktop, the
stupidity of trying to clone the windows kernel, intellectual property
considerations, etc. I can say that in all cases, the discussions were
very positive and open. I'm certain that I didn't convince everyone,
but just the opportunity to make the case was worthwhile.
The ReactOS presentation on Sunday morning went as well as can be
expected, given the state of our code. I spoke from a prepared deck
(http://plasmic.com/~vizzini) for about 15 or 20 minutes, and then we
demonstrated various aspects of the system. Steven ran the
demonstrations, which included showing off Explorer, Windows XP Notepad,
and our installation system. Then, the four of us (Steven, Art, Mark,
and me) took questions. Most of the questions this time around were
very technical in nature, and there was at least one question (from
Gavriel State, regarding our DIB engine), that pretty much stumped us
(can one of the UI guys please comment?).
We had two crashes due to the floppy driver (well, also due to my
stupidity at not configuring VMWare with a blank floppy disk image
before starting), and one non-detected mouse incident. There was also a
bit of a repainting problem, but on the whole, the system represented
itself well.
There was a very interesting question brought up on Saturday morning by
one of the Wine guys (Mike perhaps?) regarding running ReactOS inside
Linux, like Win4Lin. I was skeptical at first, but having slept on it a
day or two, I think this is a really cool idea. The proposal is that we
adapt our own ntoskrnl.exe and hal.dll to run correctly in user mode,
just like user mode linux does, and use them to run the rest of a native
Windows XP system. In other words, it replaces Win4Lin with free
software, and it would be compatible with the current Windows OSes.
Much investigating remains to be done, of course - I can't really even
guess at the level of difficulty or time required at this point - but it
is worth pursuing in my opinion.
Jan Kratochvil also joined us to present about his Captive NTFS
project. For those that don't remember what this is, Jan got the
ntfs.sys driver from Windows XP running in Linux, in part by using
chunks of ReactOS code. Jan and I had some offline discussions as well
about bringing Captive's improvements back into our tree, and about
other captive-like projects that could be implemented. I expect a lot
of focus will be applied to this area of Quasi-Wine, Quasi-ReactOS
hacking over the next year.
All in all, it was a really great conference, and I'll definitely try to
attend again next year. Presentations were good, conversations were
interesting, people were friendly, and Minnesota at -5 was beautiful!
;-)
-Vizzini
Dimitrie O. Paun wrote:
>On February 2, 2004 03:05 am, you wrote:
>
>
>>Yes, I nee help :) It's the old problem :) what task could I start :) If
>>I saw correctly in the list, regedit is implemented meantime :)
>>
>>
>
>We still need to add support for delete/rename of keys.
>
>
>
>
Ok, I all will do it :) (if I don't know something I will ask it)
Attila
Implementation of TransparentBlt
This brings up an interesting thing however..it works perfectly under windows (tested on XP), but produces strange results under wine.
MaskBlt seems to be broken, but I'm not quite sure what the cause is yet
I figured I'd send this out incase the problem is obvious to anyone
