Re: Concerning the separate OpenAL32.dll thunk patch and OpenAL winmm driver patch

[Fabian Cenedese]

At 16:08 30.11.2006 +0900, Mike McCormack wrote:

>Nick Burns wrote:
>>The patches have been split in 2 one for the thunk and one for the winmm 
>>driver.
>>Have these patches been rejected?
>>(I still dont know how to tell that -- other than checking wine-cvs)
>
>"Rejected" is a strong word.  Perhaps you could think of it as "Alexandre 
>hasn't been convinced that these patches should go in".
>
>Is openal32 a standard part of Windows?  If not, then is there a sufficient 
>number of applications using it that we should maintain this code in Wine?

Vista drops DirectSound or better said, the EAX effects won't work anymore.
That's why Creative Labs switches over to OpenAL. So it might become
much more important in the future.

http://www.openal.org/openal_vista.html
http://www.heise.de/newsticker/meldung/81212(german)

bye  Fabi

Re: Bug #6439: requesting explanation of GDI_CheckNotLock in order to fix

[Fabian Cenedese]

At 19:09 18.10.2006 -0600, you wrote:
>Alex Villací­s Lasso wrote:
>> I would like to draw attention to bug #6439
>Why that bug in particular? Can we pick any other? You seems to really
>like to copy list of all of your bugs. Hell that's turn this list into
>another Bugzilla!
>
>You know, I wanted to look at this bug when I get home. And now after
>reading your email ... I just added you to my list of bug submitters to
>ignore bugs from.

I'm not an active wine-developer, so you can put my comment wherever
you like. But if you don't pay attention you might end up on such a list
as well. He has a problem with a program, he has a bug report and he
didn't say "Please fix this bug". He intends to do it himself and just
asked for some help in understanding the code. That's already a lot
more than most other people do posting a problem here. So please
stop spreading such an unfriendly mood.

bye  Fabi

Lotus native on Linux

[Fabian Cenedese]

Hi

I just got this newsletter, thought I'd share it here:

>At my previous job, everyone in the company was forced to use Lotus Notes. I 
>recall being often annoyed with the Notes e-mail client for its clumsy user 
>interface and appalling lack of features (to say nothing of its crummy 
>calendar). The moment the platform supported POP3 mail clients, I switched to 
>Netscape Messenger.
>
>But regardless of my personal feelings about Notes, the platform eventually 
>earned my respect. The Notes developers on our IT staff built and maintained 
>several excellent applications exclusively for my department. We used those 
>applications regularly, along with our trading partners, and we quickly came 
>to depend on them. The power of Notes as a collaborative platform is clear to 
>anyone who uses it in this way.
>
>On Monday, a Notes client will be available for Linux. That s right. Companies 
>will be able to download Lotus 
>Notes on Linux 7.0.1, an Eclipse plug-in that delivers Notes client 
>functionality to Linux workstations. This includes the crummy e-mail and 
>calendar (which themselves are custom Notes apps), and other collaboration 
>software, as well as your company s own custom applications that once ran only 
>on Mac OS and Windows desktops. Initial support will be for Red Hat Enterprise 
>Linux 4, update 3, but IBM promises a version for Novell SUSE Linux Desktop 10 
>within 90 days.  
>
>Pricing starts at US$101 per client plus another $70 per client for messaging. 
>Current Mac OS and Windows licenses can be transferred.
>
>But don t be looking to code your Notes apps on a Linux box. For that, you ll 
>have to wait for the full Eclipse implementation code-named Hannover which IBM 
>says should be at milestone 3 (public beta) by this fall. Hannover will 
>implement RCP under Eclipse 3.2, and will introduce Notes to support for the 
>OpenDocument format (ODF) spec from OASIS. IBM expects general availability 
>the first half of 2007.
>
>Why did IBM wait so long to develop a Linux-based client? We were waiting for 
>Eclipse to be ready, said Arthur Fontaine, IBM s senior offering manager. The 
>company did not want to add a third code base to the MacOS and Windows bases 
>it was already maintaining.
>
>IBM sees an opportunity to enter the Linux desktop market with a lower-cost 
>alternative to Mac OS and Windows operating systems, Fontaine added. Among the 
>subtler messages IBM is sending, he said, is that we re changing to a new 
>client software development model. This has been evidenced by the 
>Eclipse-ification of its Rational tools and later this year its Sametime 7.5 
>instant messaging client. This sends a message that IBM is attacking the 
>deficit of desktop apps that Linux suffers. 
>
>Love or hate it, Lotus Notes usage in the enterprise remains strong. And 
>stronger still are the prospects of enterprise desktop Linux. For more 
>coverage of this important story, see the upcoming Aug. 1 issue of SD Times.
>
>Contact me at [EMAIL PROTECTED]
>
>Edward J. Correia

bye  Fabi

Re: Problem with explorer desktop and PAINT messages

[Fabian Cenedese]

>>Anyway I wrote a test app, showwindow.c.  It is available on
>>ftp://resnet.dnip.net . The relay log is there too. The test app tries
>>to mimic the calls I see.  I tested under wine and it does hang. I
>>will see about windows.
>
>I don't know if I did it right. I created an empty Win32 application with
>VC6, added your file, added an #include  for printf and
>compiled it successfully. Upon running a window shortly flashes
>up and the program ends, but no messages are printed to the
>command window.
>
>Most important thing I guess is that it didn't hang.

Forgot to add: That's on Windows 2000 Pro SP2.

bye  Fabi

Re: Problem with explorer desktop and PAINT messages

[Fabian Cenedese]

>Ok, I'm not sure about it waiting for that event. The call is
>0009:Call kernel32.WaitForSingleObject(0048,) ret=00401c00
>
>Anyway I wrote a test app, showwindow.c.  It is available on
>ftp://resnet.dnip.net . The relay log is there too. The test app tries
>to mimic the calls I see.  I tested under wine and it does hang. I
>will see about windows.

I don't know if I did it right. I created an empty Win32 application with
VC6, added your file, added an #include  for printf and
compiled it successfully. Upon running a window shortly flashes
up and the program ends, but no messages are printed to the
command window.

Most important thing I guess is that it didn't hang.

bye  Fabi

Re: Starcraft vs. fullscreen

[Fabian Cenedese]

>On Thu, Apr 06, 2006 at 10:18:16AM +0200, Stefan Dösinger wrote:
>> Because windows' ddraw.dll restores everything when the app exists. I've 
>> added 
>> some code to do that do my ddraw lib. I restore the screen mode when the 
>> ddraw object is released, and on the last DllMain() unload call, I loop 
>> through all ddraw objects, print their refcount, destroy all the surfaces 
>> and 
>> the ddraw object. This restores the screen res successfully.
>
>Well it's the same for memory: who in his right mind in modern operating
>system still 'free's at exit all 'malloc'ed memory :-) ?

Do you know the traveller's motto? "Leave only footprints" Meaning: don't
destroy things that don't belong to you, don't pollute other stuff, don't
leave garbage, don't rely on others to clean up after you :)

So I'd say: Everyone who has a proud in his/her code as being a round,
closed piece of work should also do the cleanup himself. I sure don't
like if some tools report that my programs have leaks, no matter what
modern, hi-tech, sophisticated OS they will run on. Call me old-fashioned :)

Sorry for the rambling.

bye  Fabi

Re: Revisiting exceptions

[Fabian Cenedese]

>> Dmitry Timoshkov wrote:
>> >Because it's patented by Borland?
>>
>> Do you have any reference to the patent? It looks to me like it is easy
>> to by-pass by using different key words and than the user can Just
>> define them to the MS ones.
>
>US Patent #5,628,016, Kukol, May 6, 1997.  And you can't patent a name, so 
>changing names won't help.
>
>But you can patent wiping your ass after defecating.  Which is basically what 
>Borland has done here.

 From this page: 
http://www.mega-tokyo.com/osfaq2/index.php/Doing%20a%20kernel%20in%20C++?version=18

---snip
http://www.codeproject.com/cpp/exceptionhandler.asp (explaining the stuff, but 
for VC++. Note that, on x86, VC++ and most other PC compilers use a stack-based 
unwinding and handling mechanism known as SEH, common to OS/2, Windows and 
Windows NT and described in detail in a famous MSJ article, 

http://www.microsoft.com/msj/0197/Exception/Exception.aspx GCC and most other 
UNIX compilers, instead, use the same table-based mechanism that is the rule on 
RISC architectures on x86 too. Also note that any use of stack-based SEH may or 
may not be covered by USPTO patent #5,628,016, held by Borland International, 
Inc. SEH on RISC architectures is table-based, thus unaffected by the patent)
---snip

The link to the patent is (without really reading all of it :)

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=5,628,016.WKU.&OS=PN/5,628,016&RS=PN/5,628,016

I wonder though: if stack-based SEH is patented by Borland, does it mean
that "VC++ and most other PC compilers" pay to Borland?

bye  Fabi

Re: Commercial support

[Fabian Cenedese]

>LOL !
>EUR $1.48  eh? I have long suspected the existance of eurodolloars  
>, now the cats out of the bag.
>
>We'ed probably be as well adopting the US constitution while we're about  
>it. It makes more sense that the wooly non-constitution they are trying to  
>ram down our throats at the moment.
>
>Still I am sure we can rely on the French to reject it . Votez NON !!

Jay Leno in response to Colin Powell's deadline for an Iraqi
constitution:
"They can take ours.  After all, we aren't using it..."

:)

bye  Fabi

Re: %Fp printf format specifier

[Fabian Cenedese]

>the net. And b.t.w., how do I get Google to not ignore the '%' in a search
>for "%Fp"?

You're out of luck (presently). I also had this problem and asked them
about it. Here's their answer:

---
Thank you for your note. Google currently does not recognize search terms
containing exclamation points, question marks, the @ sign, and other such
characters. These characters are so common that including them in a search
would greatly slow down results delivery and hurt search performance.
Furthermore, the use of punctuation on the Web is so inconsistent (for
example, there's no obvious way to decide between Mr. and Mr) that
including it in the query often does more harm than good.

That said, we know that many useful search terms do contain such
characters. We've generated exceptions for terms like C++ and are studying
ways to enable search terms like F# and C/net. We'll keep your feedback in
mind as we work to improve the quality of our search.

For more information, please visit
http://www.google.com/help/refinesearch.html . Other helpful information
can be found at http://groups.google.com in the
http://groups.google.com/groups?hl=en&group=google.public.support.generalgroup.

Please don't hesitate to contact us with any other questions or concerns.
Thanks for your interest in Google.
---


bye  Fabi

Re: Poor performance when using Texas Instruments code generation tools in Wine

[Fabian Cenedese]

>> We have done some profiling using oprofile, and found that most of this 
>> time (96%) is spent in the HEAP_FindFreeBlock* *function in the ntdll 
>> module. The time needed to locate a free heap block increases gradually, 
>> from a few iterations up to about 15000 in the project we are building. 
>> We suspect that this may be due to fragmentation caused by the heap 
>> allocate/free algorithms.
>> 
>Hi!
>  Maybe this can also explain the slowdown of long-running apps under wine ?
>For example, DC++ runs perfectly when started, but after 12 hours of operation
>the window updates, search and other program functions are so incredibly slow,
>that it's better to kill it and restart.
>   With regards, Pavel Troller

I don't know if that is specific to wine. The same happens to my edonkey on
WinXP. Uses more and more memory and also handles until a restart is the
better alternative.

bye  Fabi

Re: Pretty Good Solitaire shootout: Wine vs. Crossover

[Fabian Cenedese]

>> fixme:ole:SPCF_CreateInstance
>> (0x40a50d00,(nil),{7bf80980-bf32-101a-8bbb-00aa00300cab},0x403f1ec0),
>> creating stdpic with PICTYPE_NONE.
>> fixme:ole:OLEPictureImpl_Load Could only read 67468 of 138330 bytes in
>> no-header case?
>> fixme:ole:OLEPictureImpl_Load Unknown magic 746c, 67468 read bytes: 6c
>
>Basically what is happening here is that the format VB (sometimes) stores
>images in hasn't been fully reverse engineered. There are a few gaps in
>our knowledge.
>
>IIRC (I looked at this last summer) 0x746c means "Visual Basic resource"
>and is a trivial wrapper, the reason the code pukes out is that it seems
>to be wrapped twice or something. But I'm not sure why or what this means.

This looks like the error I already tried to fix last year (without knowing what
I did :)

http://www.winehq.org/hypermail/wine-devel/2004/01/0911.html
http://www.winehq.org/hypermail/wine-devel/2004/01/0968.html
http://www.winehq.org/hypermail/wine-devel/2004/02/0036.html
http://www.winehq.org/hypermail/wine-devel/2004/02/0053.html

Maybe that's worth trying again in your case.

bye  Fabi

Re: Wine and industrial communication like OPC

[Fabian Cenedese]

>> You could even buy copies of Windows 98 off ebay or something for 
>> ultra-cheap living. The license can be for any version of Windows AFAIK.
>
>That could perhaps be an idea
>What does AFAIK stand for?

http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=AFAIK&Find=Find

bye  Fabi

Re: config converting problem

[Fabian Cenedese]

>>Also, reinstalling all apps just because you upgraded Wine seems a bit
>>overkill, no?
>
>Well, yeah, but over time I think it becomes necessary as the contents of the initial 
>registry/config file change etc ... it's hard to know exactly what you need to do so 
>reinstalling is the easiest way.
>
>It sucks, I agree.

What was the ultimate bugfix if you have a problem in Windows? Looks like
wine is really getting close to become like Windows :)

bye  Fabi

Re: debugging a dll

[Fabian Cenedese]

>Someone sent me a debug version of a Windows dll and a map file.  I'm  
>not a Windows programmer, and I'm not sure how to use the map fiile.   

Look on the microsoft site for crashfinder (it's from a MS Journal article).
It reads the mapfile(s), you can enter an address and it returns you the
matching function.
(And if you fail to find it I can send it to you. That should be legal as the
source code is freely available.)

bye  Fabi

Re: Wine isn't GUI user friendly

[Fabian Cenedese]

At 13:31 26.07.2004 +0100, Mike Hearn wrote:
>On Mon, 26 Jul 2004 11:04:38 +0200, Fabian Cenedese wrote:
>> What about a simple GUI-application which would call wine and capture
>> (and maybe parse?) the output? This would be called if a program is
>> started with a shortcut (no console). For the console you can still use
>> the normal wine. Like that the user has at least the ability to see the
>> messages. The content is a different matter.
>
>I think that'd be rather fragile: if the message changes the gui wrapper
>breaks. Better to not hack around it and just do it in the core

Well, the parsing was just an idea. The main intent for the GUI-app
was that the user could at least see something as opposed to the
messages vanishing on the non-existent console or the ever popping
up error dialogs. The user can use the messages or he can just
discard them. And he's not forced to click on thousands of dialogs :)
Would that be the most "GUI user friendly" solution? Rewording
the errors is no good if the perfect error messages disappear in
the system :)

bye  Fabi

Re: Wine isn't GUI user friendly

[Fabian Cenedese]

>> Also, maybe we need a new debug level for that (above ERR and FIXME), 
>> which is "Human readable messages". The message as it is is perfectly 
>> understandable to programmers, but not to users. Even if it was, these 
>> messages are usually surrounded by hundred of messages that the user 
>> have no use in seeing. We should be able to let the user see only the 
>> messages that are relevant to them.
>
>Yeah, I like that idea. It could also be the first step towards moving
>certain classes of messages into a GUI form (of course it could still be
>sent to the console when you run wine like that, or be controlled by a
>config option).

What about a simple GUI-application which would call wine and capture
(and maybe parse?) the output? This would be called if a program is
started with a shortcut (no console). For the console you can still use
the normal wine. Like that the user has at least the ability to see the
messages. The content is a different matter.

bye  Fabi

Re: fix typo in wwn

[Fabian Cenedese]

>(from South Africa, where we have lions roaming the streets, no computers or 
>electricity, and Zimbabwe is like, as far as you can throw a stone to the north from 
>here)

I was just wondering how you wrote that email... :)

bye  Fabi

Re: Linux links in Windows

[Fabian Cenedese]

>I have a question about the standard drive/directory. I think there were
>some changes recently so I don't know the current state. I'm still on
>20040408 as we needed to freeze and test the source.
>
>I have a process which changes the current dir and then starts a new
>program with CreateThread. But this one is back in the old dir again.
>Shouldn't it inherit the current dir of the starting process? Is this already
>in the current wine?

Now reading it again there's something I forgot to tell :)

It works if the working dir is a real dir. But it doesn't if it is a symlink
to another place, then the cwd of the new process is like the old one
before the change.

I have (old-style config):
[Drive C]
"Path" = "%HOME%/.wine/fake_windows"

And in there is a link to another directory. Altough the _chdir into this
linked dir reports success it doesn't seem to work.

And wcmd doesn't see the link either (C:>dir).

Thanks

bye  Fabi

Linux links in Windows

[Fabian Cenedese]

Hi

I have a question about the standard drive/directory. I think there were
some changes recently so I don't know the current state. I'm still on
20040408 as we needed to freeze and test the source.

I have a process which changes the current dir and then starts a new
program with CreateThread. But this one is back in the old dir again.
Shouldn't it inherit the current dir of the starting process? Is this already
in the current wine?

Thanks

bye  Fabi

Re: additional download for winehq download page

[Fabian Cenedese]

>> This may be a fine thing to do for another project, but this is
>> not a Wine thing, sorry.
>OK, but at least the vb runtime and the win installer should be there. Nobody is
>implementing, or, AFAIK, planning to implement these parts of windows at the
>moment, and without them many programs simply have no hope of working with wine.
>We may also want to list dcom, as we even had it up on the sf page at one time.

The vbrun shouldn't be necessary as any program needing it should have
provided it in the setup itself. Even if people just try to run programs installed
on the mounted real Windows drive the dll should be seen, no? And if a prog
doesn't provide the dll it should have at least a readme to tell people where
to get it.

bye  Fabi

Re: regression: crash on X2

[Fabian Cenedese]

>Got any idea for me anyway, I can try to check patch by patch but it takes a 
>really long time recompiling each time btw can I advance cvs my 1 patch 
>or something that is smaller then date?

You can also use time, but patches come very close in time. See here for
possible date/time formats:

http://www.cvshome.org/docs/manual/cvs-1.11.15/cvs_16.html#SEC118

bye  Fabi

Re: err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this.

[Fabian Cenedese]

>I have a pretty complex default template that has a number of styles in it that all 
>render with funky true-type fonts. When you scroll up and down this list a couple of 
>times, wine ceases to render the entries. It used to lock up in an endless loop 
>somewhere, but now it bombs with the below error message.
>
>fixme:hook:NotifyWinEvent (32773,0x30035,-4,11)-stub!
>fixme:hook:NotifyWinEvent (32773,0x30035,-4,10)-stub!
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>fixme:hook:NotifyWinEvent (32773,0x30035,-4,9)-stub!
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>fixme:hook:NotifyWinEvent (32773,0x30035,-4,8)-stub!
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>fixme:hook:NotifyWinEvent (32773,0x30035,-4,7)-stub!
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>fixme:hook:NotifyWinEvent (32773,0x30035,-4,6)-stub!
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>fixme:hook:NotifyWinEvent (32773,0x30035,-4,5)-stub!
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>fixme:hook:NotifyWinEvent (32773,0x30035,-4,4)-stub!
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>fixme:hook:NotifyWinEvent (32773,0x30035,-4,3)-stub!
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>fixme:hook:NotifyWinEvent (5,0x10022,-3,0)-stub!
>fixme:ole:I_RpcWindowProc (0x10026,001c,,): stub
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes
>err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this.

This might be a similar (same?) problem as I have with my VB program.
It uses a lot of controls and wine seems to create a font for every control
even if they all have the same font style. I couldn't solve it but I had the 
same error messages (no GDI heap anymore when it tried to create a
new font).

bye  Fabi

Debugger frontend

[Fabian Cenedese]

Hi

This project is a curses based frontend for gdb. Maybe there are some
things useful for winedbg. The source view sure would make debugging
easier.

http://cgdb.sourceforge.net/

bye  Fabi

Re: Is Wine CVS broken?

[Fabian Cenedese]

>I just did and "cvs checkout" and the resulting source tree no
>longer configures/compiles.
>
>The problems seem to relate to the following directories:
>
>dlls/amstream
>dlls/dxerr8
>dlls/dxerr9
>
>which seem to have been added or removed very recently. 
>
>I tried hacking around in the configure script but couldn't get it
>to work.

I also had a problem with amstream not being updated but a fresh
checkout worked in my case.

bye  Fabi

Re: wineinstall hangs

[Fabian Cenedese]

>>Could not stat /mnt/fd0 (No such file or directory), ignoring drive A:
>
>You can safely ignore this.

Yep, I know.

>>Xlib:  extension "GLX" missing on display ":1.0".
>
>Do you have GLX compatible drivers on this maschine, is GLX activated in your 
>XF86Conig file? I often forget these trivial things...

I don't know but I thought that ./configure would pick up everything I have
or not and react accordingly. It's bad if the install fails before it's even finished.
What's GLX? It's not mentioned in my XF86Config and locate GLX only
produced two man entries. My graphic card is a Diamond Stealth 64 PCI.

>>fixme:urlmon:URLMON_DllRegisterServer (void): stub
>>wine: Unhandled exception (thread 0009), starting debugger...
>
>I get this often when RUNNING programs! :)

Yes, but already on the WINE setup?

>>Warning: Language 'us' was not recognized, defaulting to English.
>>Could not stat /mnt/fd0 (No such file or directory), ignoring drive A:
>
>Which Linux distribution do you use?

That's Knoppix (Kernel 2.4.24).

>>(hang, CTRL-C)
>
>Bad.

Yeah. Maybe there was some debugger activated but I couldn't see it.

>>But after that I could start wine regedit and the keys seem to have been
>>generated. So I don't know what really failed.
>>bye  Fabi
>
>Perhaps just warnings like the missing /mnt/fd0?

An unhandled exception and program hang is always bad. That's my
main concern. And I thought that others may have the same problem.
If not I will look into my configuration some more.

Thanks

bye  Fabi

wineinstall hangs

[Fabian Cenedese]

Hi

I just tried on a new computer to checkout wine from cvs and do a
install. Compilation worked fine, but there was again a problem with
the regedit:

--- snip ---
Preparing to install default Wine registry entries...
Installing default Wine registry entries...

Warning: Language 'us' was not recognized, defaulting to English.
Could not stat /mnt/fd0 (No such file or directory), ignoring drive A:
Xlib:  extension "GLX" missing on display ":1.0".
fixme:urlmon:URLMON_DllRegisterServer (void): stub
wine: Unhandled exception (thread 0009), starting debugger...
Warning: Language 'us' was not recognized, defaulting to English.
Could not stat /mnt/fd0 (No such file or directory), ignoring drive A:

(hang, CTRL-C)

Registry entries successfully installed.
err:seh:setup_exception nested exception on signal stack in thread 0009 eip 40108aa6 
esp 40031c28 stack 0x405a-0x406a

Installation complete for now. Good luck (this is still alpha software).
If you have problems with WINE, please read the documentation first,
as many kinds of potential problems are explained there.
--- snip ---

But after that I could start wine regedit and the keys seem to have been
generated. So I don't know what really failed.

bye  Fabi

OT: How to patch?

[Fabian Cenedese]

Hi

Not directly wine related but I'm sure also useful to others.

It was said on this list that the patches should be able to be applied
with patch (-p1) patch.diff, hence the inlining in the mail. But the patch
tool doesn't know anything about cvs. In the generated patch are infos
about the diff'd versions. So for applying a patch in my view it would be
best to update the sandbox to the version mentioned in the patch,
apply the patch (which should work without error), then update to HEAD
again. Because if you don't have the same file (maybe because the
patch was from an older version) it won't apply anymore. I know that
the unified format helps if there were small changes.
Isn't there a way to do it with cvs? I mean it can generate diffs, maybe
also apply (but I didn't find anything in the manual).
Or general question: How do others work with patches? Always with
the patch tool? Any switches I overlooked?

(This problem came up as I'm trying to create and maintain a patch so
it can be applied to the official distribution. But that's somehow useless
if it won't work with newer versions than the one were the patch was
created against, hence my idea with updating back and forth.)

Thanks

bye  Fabi

Re: Contribution offer: Localization work

[Fabian Cenedese]

>Binärdateien), unter Unix auszuführen. Es besteht aus einem Programm-
>Lader, der Microsoft Windows-Binärdateien lädt und ausführt, sowie
>einer Library (Winelib genannt), die Aufrufe der Windows API unter
>Verwendung der entsprechenden Unix- oder X11-Gegenstücke implementiert.

I take it that this is only a translation of the English file and not written by
yourself. But this sentence could lead people to believe that wine can just
be linked to normal Linux programs (-lwine) which won't be working for
a long time I think.

>Wine ist Freie Software, die unter der GNU LGPL veröffentlicht wird;
>Bitte lesen Sie die Details in der Datei LICENSE nach.

If there is a translated Readme shouldn't there also be a translated licence
file? I'm sure there is already one translated available from GNU.org. Then
this should say LIZENZ instead of LICENSE.

>Starten Sie Programme mit "wine [options] program". Weitere

Should this also be translated to "wine [optionen] programm"?

>  Desweiteren benötigen Sie flex in der Version 2.5 oder höher und yacc.

I think that should be "Des weiteren". Taken from some Internet forum:
Laut Duden _20: des weiteren, des öfteren, aber: des Nachts.

Or we could just change it to "Weiters" :)

>Mit ./configure --help können Sie sich die Konfigurations-Otionen für

Small spelling mistake.

>Nachdem der Build von Wine korrekt durchgelaufen ist, können Sie das
>Kommando "make install" aufrufen; Dadurch werden das Wine-Programm, die
>Man-Page und einige andere benötigte Dateien installiert.

Shouldn't this say "sudo make install"? I guess that should be changed in the
English version too if it's not like that.

>Wine benötigt eine Konfigurations-Datei namens "config" in Ihrem
>~/.wine-Verzeichnis. Das Format dieser Datei wird in der Man-Page der
>Konfigurations-Datei erklärt (documentation/wine.conf.man).
>Die Datei documentation/samples/config enthält eine beispielhafte
>Konfigurations-Datei, die angepasst und an die oben erwähnte Stelle
>kopiert werden muss.

I don't think it's necessary to copy the wine config yourself if you use
wineinstall (which is the recommended way). Maybe this difference should
be pointed out. (Again also applies for the English Readme file).

>umfassenden Test durch, die Ergebnisse der Überprüfungsollten sollten

Another small spelling mistake.

>Übersetzung von Christian Britz (Deutschland)
>Auf die Übersetzung bezogene Fehlermeldungen,
>Anregungen und Kommentare senden Sie bite an:
>[EMAIL PROTECTED]

Congratulations, you did a very good job. It's really a high level German you
have with very few mistakes. Most of my German business contacts don't
speak/write that well :)

bye  Fabi

Re: Sibelius 2

[Fabian Cenedese]

>When it crashes there is no useful message, only "Unhandled exception".  Using winedbg
>I have found that Sibelius appears to be following a NULL pointer.  I haven't yet
>managed to track down where it's getting the bad pointer from... any suggestions would
>be appreciated.

Maybe the NULL pointer is reasonable, but the called function doesn't check the value
and then uses it -> crash. If you make a back trace at the moment of the crash
you see the called function. Then you can test on windows if it should handle NULL
pointers or not. If not you still may have enough information to know which part the
NULL pointer came from so you can create logs with --debugmsg and the right channels.

bye  Fabi

Re: LOCALE: Don't copy value if buffer is too small

[Fabian Cenedese]

>> Ok, I saw that you fixed the WCHAR/byte mess. But there is still a possibility that
>> the function can copy a string longer than buffer if it already has an appended 
>> null.
>
>That shouldn't happen, NtQueryValue should have signaled an overflow
>in that case. Do you have a test case showing the problem?

Hmm.. not anymore. My program that failed works fine now. I started this
patch when I assumed that the length argument is in bytes. But as you
now changed all calls to WCHAR it doesn't even get to the copying
anymore. So I'm sorry, forget that patch.

Thanks

bye   Fabi

Re: VB-Error: Type mismatch

[Fabian Cenedese]

>> Contrary to my first tests these API functions understand VB hex
>> numbers quite well. There is no problem with these calls on Win2K:
>> 
>> OLECHAR test[]={'&', 'H', 'F', '0', '8', 'F', '\0'};
>> VarI4FromStr(test, LANG_NEUTRAL, NUMPRS_STD, &out);
>> VarParseNumFromStr(test, LANG_NEUTRAL, NUMPRS_STD, &np, rgb);
>> 
>> So I implemented this in wine too. If anybody has a program (mostly VB)
>> that uses hex numbers in strings please try it out. Without any other remarks
>> I'll send it to wine-patches.
>
>I believe "&O123" is a valid format also, which is how you specify an octal number in 
>VB

Yes, octal is another valid format. I think I can squeeze it in this patch
as well, most of it is already done. I also need to add another check
as they even understand &h with lower case h.

bye  Fabi

Re: VB-Error: Type mismatch

[Fabian Cenedese]

>>I'm trying (again) to run a VB app on wine. But it never shows up. Instead
>>I only see a dialog with this Type mismatch error and then it quits. I tried
>>to find the place where it goes wrong. Apparently it tries to parse a number
>>from a string in VB notation.
>>0009:trace:ole:VarParseNumFromStr (L"&H8000",1024,0x,0x408bdee0,0x408bdae0)
>
>I found that this string "&H8000" comes from my code and it's intentional.
>In VB you can convert a string to a long by using i=CLng(str). But if the
>string number is in hex format it needs to be VB hex notation. This works
>on Windows and fails on wine. I now need to find out how CLng(str)
>converts the string and why this is different on wine.

Contrary to my first tests these API functions understand VB hex
numbers quite well. There is no problem with these calls on Win2K:

OLECHAR test[]={'&', 'H', 'F', '0', '8', 'F', '\0'};
VarI4FromStr(test, LANG_NEUTRAL, NUMPRS_STD, &out);
VarParseNumFromStr(test, LANG_NEUTRAL, NUMPRS_STD, &np, rgb);

So I implemented this in wine too. If anybody has a program (mostly VB)
that uses hex numbers in strings please try it out. Without any other remarks
I'll send it to wine-patches.

bye  Fabi



Index: wine/dlls/oleaut32/variant.c
===
RCS file: /home/wine/wine/dlls/oleaut32/variant.c,v
retrieving revision 1.88
diff -u -r1.88 variant.c
--- wine/dlls/oleaut32/variant.c25 Feb 2004 01:35:01 -  1.88
+++ wine/dlls/oleaut32/variant.c25 Feb 2004 08:00:10 -
@@ -1468,6 +1468,7 @@
 #define B_EXPONENT_START  0x4
 #define B_INEXACT_ZEROS   0x8
 #define B_LEADING_ZERO0x10
+#define B_PROCESSING_HEX  0x20
 
 /**
  *  VarParseNumFromStr [OLEAUT32.46]
@@ -1698,6 +1699,33 @@
   dwState |= B_NEGATIVE_EXPONENT;
   cchUsed++;
 }
+else if ((*lpszStr == '&' && *(lpszStr+1) == 'H') &&
+ pNumprs->dwInFlags & NUMPRS_HEX_OCT &&
+ !(pNumprs->dwOutFlags & NUMPRS_EXPONENT))
+{
+  dwState |= B_PROCESSING_HEX;
+  pNumprs->dwOutFlags |= NUMPRS_HEX_OCT;
+  cchUsed=cchUsed+2;
+  lpszStr++;
+}
+else if (((*lpszStr >= 'a' && *lpszStr <= 'f') ||
+ (*lpszStr >= 'A' && *lpszStr <= 'F')) &&
+ dwState & B_PROCESSING_HEX)
+{
+  if (pNumprs->cDig >= iMaxDigits)
+  {
+return DISP_E_OVERFLOW;
+  }
+  else
+  {
+if (*lpszStr >= 'a')
+  rgbTmp[pNumprs->cDig] = *lpszStr - 'a' + 10;
+else
+  rgbTmp[pNumprs->cDig] = *lpszStr - 'A' + 10;
+  }
+  pNumprs->cDig++;
+  cchUsed++;
+}
 else
   break; /* Stop at an unrecognised character */
 
@@ -1728,14 +1756,20 @@
 /* cDig of X and writes X+Y where Y>=0 number of digits to rgbDig */
 memcpy(rgbDig, rgbTmp, pNumprs->cDig * sizeof(BYTE));
 
-while (pNumprs->cDig > 1 && !rgbTmp[pNumprs->cDig - 1])
-{
-  if (pNumprs->dwOutFlags & NUMPRS_DECIMAL)
-pNumprs->nPwr10--;
-  else
-pNumprs->nPwr10++;
+if (dwState & B_PROCESSING_HEX) {
+  /* hex number have always the same format */
+  pNumprs->nPwr10=0;
+  pNumprs->nBaseShift=4;
+} else {
+  while (pNumprs->cDig > 1 && !rgbTmp[pNumprs->cDig - 1])
+  {
+if (pNumprs->dwOutFlags & NUMPRS_DECIMAL)
+  pNumprs->nPwr10--;
+else
+  pNumprs->nPwr10++;
 
-  pNumprs->cDig--;
+pNumprs->cDig--;
+  }
 }
   } else
   {
@@ -1870,7 +1904,110 @@
   if (pNumprs->nBaseShift)
   {
 /* nBaseShift indicates a hex or octal number */
-FIXME("nBaseShift=%d not yet implemented, returning overflow\n", 
pNumprs->nBaseShift);
+ULONG64 ul64 = 0;
+LONG64 l64;
+int i;
+
+/* Convert the hex or octal number string into a UI64 */
+for (i = 0; i < pNumprs->cDig; i++)
+{
+  if (ul64 > ((UI8_MAX>>pNumprs->nBaseShift) - rgbDig[i]))
+  {
+TRACE("Overflow multiplying digits\n");
+return DISP_E_OVERFLOW;
+  }
+  ul64 = (ul64= I1_MIN)))
+{
+  V_VT(pVarDst) = VT_I1;
+  if (ul64 <= I1_MAX)
+  V_I1(pVarDst) = ul64;
+  else
+  V_I1(pVarDst) = l64;
+  return S_OK;
+}
+else if (dwVtBits & VTBIT_UI1 && ul64 <= UI1_MAX)
+{
+  V_VT(pVarDst) = VT_UI1;
+  V_UI1(pVarDst) = ul64;
+  return S_OK;
+}
+else if (dwVtBits & VTBIT_I2 && ((ul64 <= I2_MAX)||(l64 >= I2_MIN)))
+{
+  V_VT(pVarDst) = VT_I2;
+  if (ul64 <= I2_MAX)
+  V_I2(pVarDst) = ul64;
+  else
+  V_I2(pVarDst) = l64;
+  return S_OK;
+}
+else if (dwVtBits & VTBIT_UI2 && ul64 <= UI2_MAX)
+{
+  V_VT(pVarDst) = VT_UI2;

RFC: OlePicture patch

[Fabian Cenedese]

Hi

Can anybody comment on this?

http://www.winehq.org/hypermail/wine-patches/2004/02/0121.html

I know that it's not the best solution (or if it is it's without explanation).
I tried to find anything about this magic number but I found nothing.
Unless someone has a reason _not_ to apply it I vote in favour of it.
It helps VB programs with the SSTab control without pictures
assigned to the tabs to load properly. As there are no pictures
it shouldn't read more data from the stream and try to create a
picture with wrong data.

Thanks

bye  Fabi

Re: buffer too small for currency

[Fabian Cenedese]

>   Fabian> If I don't hear anything I'll take the easy road and send in a
>Fabian> patch :)
>
>As always, it is a good idea to write a testcase in dlls/kernel/tests to
>document this error...

Of course, but I can only write a test if I know what to test/what the
results should be, that's why I'm asking...

bye  Fabi

Re: buffer too small for currency

[Fabian Cenedese]

>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.

I continued this one too (I don't like unhandled exceptions :)
I found the problem but not how to solve it. It's in the file locale.c
As it stands now the value gets copied even if the buffer is too small which
nicely destroys the stack.

static INT get_registry_locale_info( LPCWSTR value, LPWSTR buffer, INT len )
{
--snip--

if (!status)
{
ret = (size - info_size) / sizeof(WCHAR);
/* append terminating null if needed */
if (!ret || ((WCHAR *)info->Data)[ret-1])
{
if (ret < len || !buffer) ret++;
else
{
SetLastError( ERROR_INSUFFICIENT_BUFFER );
ret = 0;
}
}
if (ret && buffer)
{
memcpy( buffer, info->Data, (ret-1) * sizeof(WCHAR) );
buffer[ret-1] = 0;
}


The found value (info->Data) should only be copied to (buffer) if its length (len)
is big enough. len is given in bytes (8 for the above call with a buffer of 4 WCHARs).
But the length of the data (ret) is in WCHAR units. So the comparison here
is completely wrong. Ok, I could change this to len/sizeof(WCHAR). But that's
still not enough because of the comparison before about info->Data[ret-1].

ret is calculated as 5 for the string "SFr.". I don't know if it's correct that it
includes the ending null. If it is then the test needs to be on info->Data[ret-2].
But if the size should be 4 somebody else needs to check which of these
(partly undocumented) functions should return a different size.

If I don't hear anything I'll take the easy road and send in a patch :)

Thanks

bye  Fabi

Re: Big hex numbers negative?

[Fabian Cenedese]

>> >double dVal;
>> >OLECHAR test1[]={'&', 'H', '8', '0', '0', '0', '0', '0', '0', '0', '\0'};
>> >ok=VarR8FromStr(test1, LANG_NEUTRAL, NUMPRS_STD, &dVal);
>> >
>> >The result for dVal was -2147483648. But as a real value it shouldn't
>> >have any problems holding the "real" value 2147483648. So why has
>> >it become negative? Is it because the source form was a hex number?
>> >Are all hex numbers automatically signed if converted to int/real? Or
>> >just because of the 32nd bit? The documentation wasn't that informative.
>> >
>> >(The funny thing though was this remark in my VC6 help, it's not
>> >in the online version of MSDN anymore:
>> >Passing into this function any invalid and, under some circumstances, NULL
>> > pointers will result in unexpected termination of the application. For
>> > more information about handling exceptions, see Programming
>> > Considerations.
>> >
>Now does that mean "invalid numbers" or "invalid pointers"?  Are they just 
>saying that they hadn't included IsBadReadPtr in the argument checking?

I don't know, that was the only remark. But the same remark is included
in all VarXXFromYY functions.

>> I'm not sure I understood your question properly.
>> A signed 2 complement 32 bit var can hold the numbers (-2^31) to
>> (2^31)-1. That's just how the encoding works. Was that your question?
>>
>>  Shachar
>Because there is nothing explicitly in there about 32 bit representations.  It 
>goes from a string of characters to a (excuse my ignorance) 64 bit double 
>prescision.  So are there restrictions on what character strings can be 
>passed in?  e.g. what would it do with "&H8000"?

My original question was if this conversion works implicitly with a signed
hex string even if hex can be anything. Strings with more than 8 significant
chars are rejected (DISP_E_OVERFLOW). So I guess these conversions
assume at the most a signed long. That's how I will implement them then.

Thanks

bye  Fabi

Re: Winedbg that catches exception raised in IsBadReadPtr

[Fabian Cenedese]

>Winedbg catches the exception raised and handled in a __TRY/__EXCEPT/__ENTRY 
>statement in the IsBadReadPtr function.
>Is it a normal behaviour? And if yes how can I disable it?
>Without Winedbg everything is fine.

Winedbg catches every exception. But you can pass it on to the application
with 'pass'. Then it should continue normally. Of course this can happen
several times. And if there are many it makes this a long task. But there's
no way of switching this off.

bye  Fabi

Big hex numbers negative?

[Fabian Cenedese]

Hi

While testing more variant functions I tried this on Windows:

double dVal;
OLECHAR test1[]={'&', 'H', '8', '0', '0', '0', '0', '0', '0', '0', '\0'};
ok=VarR8FromStr(test1, LANG_NEUTRAL, NUMPRS_STD, &dVal);

The result for dVal was -2147483648. But as a real value it shouldn't
have any problems holding the "real" value 2147483648. So why has
it become negative? Is it because the source form was a hex number?
Are all hex numbers automatically signed if converted to int/real? Or
just because of the 32nd bit? The documentation wasn't that informative.

(The funny thing though was this remark in my VC6 help, it's not
in the online version of MSDN anymore:
Passing into this function any invalid and, under some circumstances, NULL pointers 
will result in unexpected termination of the application. For more information about 
handling exceptions, see Programming Considerations.

...now I understand many things :)

Thanks

bye   Fabi

Re: VarRound implementation

[Fabian Cenedese]

>be. You have 2 choices: try and match their exact algorithm (v. hard
>w/o reverse engineering) or use the dutch rounding method (this makes
>more sense IMO).

I couldn't find anything about "Dutch rounding". Isn't rounding exactly
defined? 0.1-0.4 round down -> 0.0, 0.5-0.9 round up -> 1.0?

>> And how should I round a currency? It's valid on Windows but I
>> couldn't interpret the results. 
>> Is this some kind of fixed comma type?
>
>The currency value is multiplied by 1 and stored in an I8 (See
>the VarCy* functions). So it has 4 dp of precision. To round to:
>
>4 dp or more => no op.
>0 dp => / 1, then * 1
>1 dp => / 1000, then * 1000
>2 dp => / 100, then * 100
>3 dp => / 10, then * 10
>
>mults and divs should be done on the I8 directly (no float).

I think I did it like this now. Still the DECIMAL part is missing. The tests
in the test_VarRound are commented out as compares on floats are
quite useless. Unless somebody finds a better way to test if the rounding
worked ok I'll remove them (which would be a pity).

bye  Fabi



Index: wine/dlls/oleaut32/oleaut32.spec
===
RCS file: /home/wine/wine/dlls/oleaut32/oleaut32.spec,v
retrieving revision 1.64
diff -u -r1.64 oleaut32.spec
--- wine/dlls/oleaut32/oleaut32.spec21 Jan 2004 22:24:08 -  1.64
+++ wine/dlls/oleaut32/oleaut32.spec23 Feb 2004 10:46:42 -
@@ -170,7 +170,7 @@
 172 stdcall VarInt(ptr ptr)
 173 stdcall VarNeg(ptr ptr)
 174 stdcall VarNot(ptr ptr)
-175 stub VarRound # stdcall (ptr long ptr)
+175 stdcall VarRound(ptr long ptr)
 176 stdcall VarCmp(ptr ptr long long)
 177 stdcall VarDecAdd(ptr ptr ptr)
 178 stdcall VarDecDiv(ptr ptr ptr)
Index: wine/dlls/oleaut32/variant.c
===
RCS file: /home/wine/wine/dlls/oleaut32/variant.c,v
retrieving revision 1.87
diff -u -r1.87 variant.c
--- wine/dlls/oleaut32/variant.c17 Feb 2004 20:25:41 -  1.87
+++ wine/dlls/oleaut32/variant.c23 Feb 2004 10:46:43 -
@@ -3436,6 +3436,135 @@
 
 return hRet;
 }
+
+
+/**
+ *  VarRound [OLEAUT32.175]
+ *
+ * Perform a round operation on a variant.
+ *
+ * PARAMS
+ *  pVarIn  [I] Source variant
+ *  deci[I] Number of decimals to round to
+ *  pVarOut [O] Destination for converted value
+ *
+ * RETURNS
+ *  Success: S_OK. pVarOut contains the converted value.
+ *  Failure: An HRESULT error code indicating the error.
+ *
+ * NOTES
+ *  - Floating point values are rounded to the desired number of decimals.
+ *  - Negative values are rounded nearer to zero (and not bigger in absolute).
+ *  - Some integer types are just copied to the return variable.
+ *  - Some other integer types are not handled and fail.
+ */
+HRESULT WINAPI VarRound(LPVARIANT pVarIn, int deci, LPVARIANT pVarOut)
+{
+VARIANT varIn;
+HRESULT hRet = S_OK;
+float factor;
+
+TRACE("(%p->(%s%s),%d)\n", pVarIn, debugstr_VT(pVarIn), debugstr_VF(pVarIn), 
deci);
+
+switch (V_VT(pVarIn))
+{
+/* cases that fail on windows */
+case VT_I1:
+case VT_I8:
+case VT_UI2:
+case VT_UI4:
+   hRet = DISP_E_BADVARTYPE;
+   break;
+
+/* cases just copying in to out */
+case VT_UI1:
+   V_VT(pVarOut) = V_VT(pVarIn);
+   V_UI1(pVarOut) = V_UI1(pVarIn);
+   break;
+case VT_I2:
+   V_VT(pVarOut) = V_VT(pVarIn);
+   V_I2(pVarOut) = V_I2(pVarIn);
+   break;
+case VT_I4:
+   V_VT(pVarOut) = V_VT(pVarIn);
+   V_I4(pVarOut) = V_I4(pVarIn);
+   break;
+case VT_NULL:
+   V_VT(pVarOut) = V_VT(pVarIn);
+   /* value unchanged */
+   break;
+
+/* cases that change type */
+case VT_EMPTY:
+   V_VT(pVarOut) = VT_I2;
+   V_I2(pVarOut) = 0;
+   break;
+case VT_BOOL:
+   V_VT(pVarOut) = VT_I2;
+   V_I2(pVarOut) = V_BOOL(pVarIn);
+   break;
+case VT_BSTR:
+hRet = VarR8FromStr(V_BSTR(pVarIn), LOCALE_USER_DEFAULT, 0, &V_R8(&varIn));
+if (FAILED(hRet))
+break;
+pVarIn = &varIn;
+/* Fall through ... */
+
+/* cases we need to do math */
+case VT_R8:
+   if (V_R8(pVarIn)>0) {
+   V_R8(pVarOut)=floor(V_R8(pVarIn)*pow(10, deci)+0.5)/pow(10, deci);
+   } else {
+   V_R8(pVarOut)=ceil(V_R8(pVarIn)*pow(10, deci)-0.5)/pow(10, deci);
+   }
+   V_VT(pVarOut) = V_VT(pVarIn);
+   break;
+case VT_R4:
+   if (V_R4(pVarIn)>0) {
+   V_R4(pVarOut)=floor(V_R4(pVarIn)*pow(10, deci)+0.5)/pow(10, deci);
+   } else {
+   V_R4(pVarOut)=ceil(V_R4(pVarIn)*pow(10, deci)-0.5)/pow(10, deci);
+   }
+   V_VT(pVarOut) = V_VT(pVarIn);
+   break;
+case VT_DATE:
+   if (V_DATE(pVarIn)>0) {
+   V_DATE(pVarOut)=floor(V_DATE(pVarIn)*pow(10, deci)+0.5)/pow(10, deci);
+   } else {
+   V_DATE(pVarOut)=ceil(V_DATE(pVarI

Re: DLL, shared library, ...

[Fabian Cenedese]

>  I would like to ask you if there is a way how to convert .dll
>library to the Linux .so library? This library contains simple
>functions (something like voice codec) "without any dependency" on the
>Windows operating system - it's "platform independet", but packed into
>the .dll.
>
>  I'm trying google, wine mailing list archives and I can't find
>anything about this issue. Do you think it's possible to do this or
>should I forgot and fight for the source code?

If your dll code is already C/C++ the easiest would be to create a new
.so project (e.g. with KDevelop) and then copy/paste the dll functions
to your .so project.

bye  Fabi

Re: +relay stops window output?

[Fabian Cenedese]

>[snip]
>> But +relay makes the application... invisible :) Maybe someone
>> could have a look at it.
>[snip]
>
>LOL :-) You should send those two phrases to microsoft support, it would 
>make an interesting turing test.

Yeah, reading it again I maybe could have phrased that better. But considering
that English is not my native language I think I'm doing ok.

>PS: Sorry for the OT post, but this brightened up an otherwise dull lunch 
>break.

No problem, at least it was good for some fun. I hope you didn't spill anything
on your keyboard :)

bye  Fabi

Re: +relay stops window output?

[Fabian Cenedese]

>I have a problem with debugging. Since cvs update today I can't use
>+relay anymore. The app window comes up but doesn't show any
>content. It's just an empty frame with dead visuals and doesn't react.
>I can drag the frame and close it. But it works ok if I e.g. have +ole.
>Same is with other apps which worked last week.

I was wondering as nobody stated similar problems. Only Uwe
Bonnes confirmed via private mail having similar effects. I updated from
earlier cvs wine versions and found the time where it broke. It was
at cvs -D"2004-02-13 21:27", so about one week ago. I guess the
responsible patch was this (at least it's about painting :)

http://www.winehq.org/hypermail/wine-cvs/2004/02/0160.html

I don't know how this could have something to do with debugging.
But +relay makes the application... invisible :) Maybe someone
could have a look at it.

Thanks

bye  Fabi

Re: VarRound implementation

[Fabian Cenedese]

>Without a test how can you know if this implementation produces the correct values?  
>What about variant type conversions?  It seems silly to send a patch without testing 
>it...

Now I'm confused. I'm adding more types to VarRound and I'm also implementing
the test_VarRound function (programmer's pride :)

For this I tested more cases on Windows and got strange results (in my view).

VT_R4: 7.850 -> VarRound(1) -> 7.800
VT_R4: 7.851 -> VarRound(1) -> 7.900

Is this the binary representation (in)accuracy?
How can I test if the rounding worked ok when the numbers may differ in
the last (invisible) bits?

And how should I round a currency? It's valid on Windows but I couldn't
interpret the results. Is this some kind of fixed comma type?

bye  Fabi

Re: VarRound implementation

[Fabian Cenedese]

>Without a test how can you know if this implementation produces the correct values?  
>What about variant type conversions?  It seems silly to send a patch without testing 
>it...

I just saw that I submitted a patch with some debug code in it. I guess I'll
have to send it again anyway :)

bye  Fabi

Re: VarRound implementation

[Fabian Cenedese]

>Without a test how can you know if this implementation produces the correct values?  
>What about variant type conversions?  It seems silly to send a patch without testing 
>it...

I didn't mean that I never tested it. Of course I had a test program with which
I found out what results Windows would give me. Then I implemented this
function until my test program gave me the same results as on Windows.
But that was a standalone MFC program. I meant that I tried to make a
test_VarRound function so it could be tested automatically for regressions.
That's where I failed. But the function itself is tested (for the implemented
variant types). I just made the most important types (as are in other
functions such as VarAnd and VarOr) as this will help in the most cases.
I don't know how many people will use Round on anything other than
real types. It sure helped me. And if another type is needed the main
work is already done.
So if somebody else wants to write a test_VarRound please do. If more
work is needed on VarRound please tell me and I do.

bye  Fabi

Win Api Monitor

[Fabian Cenedese]

Hi

For figuring out what my program does on Windows I was looking for
an Api Monitor, kinda the Windows counterpart of +relay. So I came
across this page. It didn't quite help me but it's maybe useful for others.
Just be sure to set a process filter or your computer will stop responding
as it's overflowed with messages (as happened with me :)

http://www.rohitab.com/apimonitor/

bye  Fabi

Re: bt in traces

[Fabian Cenedese]

>this would be as intrusive as using the debugger (I assume that the running process 
>would be in charge of printing the backtrace, or an external process - like a 
>debugger - would print the backtrace, while the program is stopped (or after copying 
>the stack for instrospection, which dbghelp doesn't provide btw))
>Fabi (another thought), did you try to add DbgBreak(); in the function itself and use 
>bt in the debugger ?

That may work (I haven't tried) but would only be useful for some cases. The
one where it didn't stop on the bp would be one. But there are others. If I
want to look at a function which is called many times (hundreds) and I'm
only interested in the one time it fails I don't want to 'cont' as many times.
Second is that winedbg catches every exception, handled or not. For a
small test program this is no problem. But for bigger real life apps with
exceptions and internal handling this makes them almost unusable.
Always falling back to winedbg and 'pass' or 'cont' is not really running
a program. Winedbg is ok, I also use it when I can. But most of the
time debug logs (with some own messages) are more helpful to me.

bye  Fabi

ListView oddity

[Fabian Cenedese]

Hi

I had a problem with the ListView control. I could circumvent it by changing
(correcting?) my application. But I thought I'd still report it.

I have an MFC-app which uses a CListCtrl-derived list. In the OnRButtonDown
handler of my class I didn't call the baseclass handler from CListCtrl. Upon
release of the right mouse button the context menu would appear on Windows.
That's how it worked.

On wine I can see that the LISTVIEW_RButtonDown function is never called.
Understandable as I didn't call the base class. But in this handler is a flag
called bRButtonDown which would be set to TRUE. In the corresponding
handler LISTVIEW_RButtonUp this flag is again tested. As it was never
set in my case the handler never sent the WM_CONTEXTMENU message.

What is this flag for? Is this to detect drag'n'drops with the right button or
something like that? As my app worked on Windows I guess it's not
necessary that the ButtonDown handler is called as in wine. Or this
flag should be set earlier and not in the (maybe not called) down handler.
Or it could be cleared from mouse move messages, don't know.

As I said I corrected my app to always call the base class handler and so
it works now. But that's a difference to Windows that may need to be
changed sometimes. I wonder why it worked on Windows anyway :)

Thanks

bye  Fabi

Re: bt in traces

[Fabian Cenedese]

>>Is it possible to output the backtrace while the program is running? I
>>mean that with a new debug command e.g. wine_dbg_bt or so you
>>could output not only the name of the called function and the argument
>>values (as with the debug channels) but also the call stack where it
>>came from. That's of course only temporarily for debugging inside
>>wine. If I see that a function has a problem because the argument is
>>wrong it would be much easier to find out where this came from.
>>If I only want to use it inside wine it should have access to the
>>call stack information, no?
>
>why can't you Just use a debugger?

One thing is that I have a problem with breakpoints, winedbg just
rushes through as explained here: ...  hmm, can't access winehq
again. Mail was "WineDbg didn't stop" from 22.01.2004.

But besides that: I like to have the full picture of what was going on,
from program start to end. And it could also be that a function was
called differently on different occasions. (If there was only one possibility
a simple grep would give me the answer). So a log with some call
stacks would be nice. But if this is too complicated then ok, I just
thought that would be a usefull tool.

bye  Fabi

bt in traces

[Fabian Cenedese]

Hi

Is it possible to output the backtrace while the program is running? I
mean that with a new debug command e.g. wine_dbg_bt or so you
could output not only the name of the called function and the argument
values (as with the debug channels) but also the call stack where it
came from. That's of course only temporarily for debugging inside
wine. If I see that a function has a problem because the argument is
wrong it would be much easier to find out where this came from.
If I only want to use it inside wine it should have access to the
call stack information, no?

Thanks

bye  Fabi

ListView patch

[Fabian Cenedese]

Hi

I submitted this patch two weeks ago and it doesn't seem to have been
applied. Is there something wrong with it? Should I resend?

http://www.winehq.org/hypermail/wine-patches/2004/02/0010.html

Thanks

bye  Fabi

Re: CopyFile fails sometimes

[Fabian Cenedese]

>Actually that's wrong :)  It works if I call the copy tool directly with wine.
>But calling the batch file with wineconsole gives the same error. So it
>could be that wineconsole/batch files/dos mode/whatever don't like
>the very long extensions or the chars contained. Yep, it doesn't like
>the _ after the dot. After removing the underscore it works also with
>the wineconsole. Any ideas?

Seems like that was an error on my side. The copying went fine but
there was an +*ç%" command after the copy in the batchfile which
changed the files. That's why I thought the copy went wrong. Sorry
for the noise.

bye  Fabi

+relay stops window output?

[Fabian Cenedese]

Hi

I have a problem with debugging. Since cvs update today I can't use
+relay anymore. The app window comes up but doesn't show any
content. It's just an empty frame with dead visuals and doesn't react.
I can drag the frame and close it. But it works ok if I e.g. have +ole.
Same is with other apps which worked last week.

Is this a known problem?

Thanks

bye  Fabi

Re: VB-Error: Type mismatch

[Fabian Cenedese]

>I'm trying (again) to run a VB app on wine. But it never shows up. Instead
>I only see a dialog with this Type mismatch error and then it quits. I tried
>to find the place where it goes wrong. Apparently it tries to parse a number
>from a string in VB notation.
>0009:trace:ole:VarParseNumFromStr (L"&H8000",1024,0x,0x408bdee0,0x408bdae0)

I found that this string "&H8000" comes from my code and it's intentional.
In VB you can convert a string to a long by using i=CLng(str). But if the
string number is in hex format it needs to be VB hex notation. This works
on Windows and fails on wine. I now need to find out how CLng(str)
converts the string and why this is different on wine.

bye   Fabi

Re: LOCAL: Not enough space in GDI heap

[Fabian Cenedese]

>>I suspect your leak happens in the olefont implementation.  You want
>>to check that each hfont is destroyed when the IOleFont interface is
>>released.
>
>When are the fonts released? If a control creates a font and uses it until
>the dialog gets closed it doesn't help much. There will still be too many
>fonts while running. Or should the control create a font every time it has
>to draw anything and will release it again after? I can see releases but
>the reference counter never reaches 0 until the end of the program where
>all remaining fonts are cleaned up.

I didn't really get further. Everything looks normal if these assumptions and
observations are correct:

- The freetype engine will cache every font for every different handle.
- And as CreateFontIndirect returns a different handle on every call the engine
  will also cache as many fonts (if they are used).
- The VB runtime will create a font for every control as they can be different.
  (At least it looks like that with dozens of calls to CreateFontIndirect and
  therefore many different font handles).
- A font will only get deleted from cache if the program does so, not from
  wine itself.
- As there is no error in the end about references not being 0 or so I guess
  that every GetObject also has a matching ReleaseObject. But the timing
  may be different to windows. (Tested with a simple app which works ok
  but still uses as many fonts as there are controls even if all are the same).

Is there a possibility to increase the GDI heap? Like that I could at least
test if the app works ok besides this font problem. I ran it again on Windows
and looked at the resources. It only uses 40 fonts while running, but I
don't know about the startup. Comparing this to the wine stats it seems
that Windows can use the same fonts for different controls. Or it does
release and reallocate them on demand.

So I'm out of powder again. If anybody wants to test it I can send the
application.

Thanks

bye  Fabi

Re: CopyFile fails sometimes

[Fabian Cenedese]

>>FILE: FILE_CreateFile: 
>>/home/fabi/winec/imp2/Config/_ConfigurationType._TemplInfoLinkMaster_
>
>There are several files like that but in the destination directory I get only one
>single file with the name "_ConfigurationType" with which they all begin with.
>The content is the one from the last file being copied. So it looks like the
>CreateFile somehow messed up the name as everything else worked and
>copied all files over each other. I traced it until the call to the server in
>FILE_CreateFile. I only had a look at the server code but couldn't see anything
>where the filename is analyzed (except for .exe and .com). Other files are
>copied without any problem, with or without extension, even extensions longer
>than 3 chars.
>
>But it gets even weird. My copy tool is a Win32 CLI app. I have a batch
>file which calls this copy tool to copy several files (of course). If this batch
>file again is called from a Win32 MFC+GUI app I get this described error. But
>if I call it directly with wineconsole batch.bat the whole copying works.
>So it may have to do with execution/redirection. But I'm out again.

Actually that's wrong :)  It works if I call the copy tool directly with wine.
But calling the batch file with wineconsole gives the same error. So it
could be that wineconsole/batch files/dos mode/whatever don't like
the very long extensions or the chars contained. Yep, it doesn't like
the _ after the dot. After removing the underscore it works also with
the wineconsole. Any ideas?

bye  Fabi

CopyFile fails sometimes

[Fabian Cenedese]

Hi

I wrote my own little copy program which mostly works with CopyFile.
It does so quite well but it fails on some file(name)s. Here is the trace
of copying two files with admittedly unusual filenames:

trace:file:CopyFileW L"_ConfigurationType._TemplInfoLinkMaster_" -> 
L"C:\\imp2\\Config\\_ConfigurationType._TemplInfoLinkMaster_"
trace:file:CreateFileW L"_ConfigurationType._TemplInfoLinkMaster_" GENERIC_READ 
FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING  attributes 0x0
FABI: FILE: FILE_CreateFile: 
/home/fabi/winec/IMD/Templates/InosConfiguration/_ConfigurationType._TemplInfoLinkMaster_
trace:file:CreateFileW returning 0x10
trace:file:GetFileInformationByHandle 0x10
trace:file:CreateFileW L"C:\\imp2\\Config\\_ConfigurationType._TemplInfoLinkMaster_" 
GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WRITE CREATE_ALWAYS  attributes 0x20
FABI: FILE: FILE_CreateFile: 
/home/fabi/winec/imp2/Config/_ConfigurationType._TemplInfoLinkMaster_
trace:file:CreateFileW returning 0x28
trace:file:ReadFile 0x10 0x408ceeb0 2048 0x408ceea8 (nil)
trace:file:WriteFile 0x28 0x408ceeb0 130 0x408ceeac (nil)
trace:file:ReadFile 0x10 0x408ceeb0 2048 0x408ceea8 (nil)

trace:file:CopyFileW L"_ConfigurationType._TemplInfoPpcISM_" -> 
L"C:\\imp2\\Config\\_ConfigurationType._TemplInfoPpcISM_"
trace:file:CreateFileW L"_ConfigurationType._TemplInfoPpcISM_" GENERIC_READ 
FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING  attributes 0x0
FABI: FILE: FILE_CreateFile: 
/home/fabi/winec/IMD/Templates/InosConfiguration/_ConfigurationType._TemplInfoPpcISM_
trace:file:CreateFileW returning 0x10
trace:file:GetFileInformationByHandle 0x10
trace:file:CreateFileW L"C:\\imp2\\Config\\_ConfigurationType._TemplInfoPpcISM_" 
GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WRITE CREATE_ALWAYS  attributes 0x20
FABI: FILE: FILE_CreateFile: 
/home/fabi/winec/imp2/Config/_ConfigurationType._TemplInfoPpcISM_
trace:file:CreateFileW returning 0x28
trace:file:ReadFile 0x10 0x408ceeb0 2048 0x408ceea8 (nil)
trace:file:WriteFile 0x28 0x408ceeb0 124 0x408ceeac (nil)
trace:file:ReadFile 0x10 0x408ceeb0 2048 0x408ceea8 (nil)


There are several files like that but in the destination directory I get only one 
single
file with the name "_ConfigurationType" with which they all begin with. The content
is the one from the last file being copied. So it looks like the CreateFile somehow
messed up the name as everything else worked and copied all files over each
other. I traced it until the call to the server in FILE_CreateFile. I only had a look
at the server code but couldn't see anything where the filename is analyzed
(except for .exe and .com). Other files are copied without any problem, with
or without extension, even extensions longer than 3 chars.

But it gets even weird. My copy tool is a Win32 CLI app. I have a batch
file which calls this copy tool to copy several files (of course). If this batch
file again is called from a Win32 MFC+GUI app I get this described error. But
if I call it directly with wineconsole batch.bat the whole copying works.
So it may have to do with execution/redirection. But I'm out again.

Anything I could test?

Thanks

bye  Fabi

VB-Error: Type mismatch

[Fabian Cenedese]

Hi

Who invented VB...? Ah yeah, right...

I'm trying (again) to run a VB app on wine. But it never shows up. Instead
I only see a dialog with this Type mismatch error and then it quits. I tried
to find the place where it goes wrong. Apparently it tries to parse a number
from a string in VB notation.
0009:trace:ole:VarParseNumFromStr (L"&H8000",1024,0x,0x408bdee0,0x408bdae0)

With my own debug messages I found that it bails out with this reason:
ole:VarParseNumFromStr: Not all chars were consumed

This leads to a nice exception which is caught from the VB dll:
0009:Call kernel32.RaiseException(c08f,0001,0002,408be0c8) ret=6a87479d
0009:trace:seh:EXC_RtlRaiseException code=c08f flags=1 addr=0x404b9b30
0009:trace:seh:EXC_RtlRaiseException  info[0]=deadcafe
0009:trace:seh:EXC_RtlRaiseException  info[1]=deadcafe
0009:trace:seh:EXC_RtlRaiseException  eax=408bdf70 ebx=4057691c ecx= 
edx=0004 esi=408be0d0 edi=408bdf8c
0009:trace:seh:EXC_RtlRaiseException  ebp=408bdfcc esp=408bdf70 cs=0023 ds=002b 
es=002b fs=1007 gs= flags=0212
0009:trace:seh:EXC_CallHandler calling handler at 0x11004246 code=c08f flags=1
0009:CALL MSVBVM60.__vbaExceptHandler((0x4034,0002,0040): returning 42b4c020
) ret=401cac8b

And this in return presents me the nice error dialog.
0009:trace:resource:LoadStringW L"Type mismatch" loaded !

Is this function VarParseNumFromStr supposed to understand VB notation
as well? The docs from MS I found don't say anything about how the numbers
have to be formed to be parsed well. In a small test program in C I only got
the same result on Windows for these parameters. So the implementation
seems ok so far. But then where did this string come from? Some
property?

0009:Call oleaut32.SysAllocStringLen(42b4b70c L"FontColor",0009) ret=6a939fac
0009:trace:heap:RtlAllocateHeap (0x4034,0002,0018): returning 42b4b6a8
0009:Ret  oleaut32.SysAllocStringLen() retval=42b4b6ac ret=6a939fac
0009:Call user32.CharUpperBuffW(42b4b6ac L"FontColor",000a) ret=6a934b66
0009:Ret  user32.CharUpperBuffW() retval=000a ret=6a934b66
0009:RET  MSVBVM60.rtcUpperCaseVar() retval=408be230 ret=1102ff69
0009:CALL MSVBVM60.__vbaVarTstEq(408be1e0,408be230) ret=1102ff8e
0009:Call oleaut32.VarCmp(408be230,408be1e0,,00030001) ret=6a94f05b
0009:trace:ole:VarCmp 
(0x408be230->(VT_BSTR),0x408be1e0->(VT_BSTR|VT_HARDTYPE),0x,0x00030001)
0009:trace:ole:VariantInit (0x408bdff8)
0009:trace:ole:VariantInit (0x408be008)
0009:Call kernel32.CompareStringW(,00030001,42b4b6ac 
L"FONTCOLOR",,1100b858 L"VALUE",) ret=40c164be
0009:Ret  kernel32.CompareStringW() retval=0001 ret=40c164be
0009:Ret  oleaut32.VarCmp() retval= ret=6a94f05b
0009:RET  MSVBVM60.__vbaVarTstEq() retval= ret=1102ff8e
0009:CALL MSVBVM60.__vbaFreeVar() ret=1102ff96
0009:Call oleaut32.SysFreeString(42b4b6ac L"FONTCOLOR") ret=6a94f0df
0009:trace:heap:RtlFreeHeap (0x4034,0002,42b4b6a8): returning TRUE
0009:Ret  oleaut32.SysFreeString() retval=0001 ret=6a94f0df
0009:RET  MSVBVM60.__vbaFreeVar() retval=0001 ret=1102ff96
0009:CALL MSVBVM60.rtcMidCharVar(408be220,408be1f0,0003,408be230) ret=1102
0009:Call oleaut32.SysAllocStringByteLen(42b4bfb8,0008) ret=6a8742d9
0009:trace:heap:RtlAllocateHeap (0x4034,0002,0018): returning 42b4b6a8
0009:Ret  oleaut32.SysAllocStringByteLen() retval=42b4b6ac ret=6a8742d9
0009:RET  MSVBVM60.rtcMidCharVar() retval=408be220 ret=1102
0009:CALL MSVBVM60.__vbaVarCat(408be210,408be220,408be1d0) ret=11030014
0009:Call oleaut32.VarCat(408be1d0,408be220,408be210) ret=6a938e10
0009:trace:ole:VarCat (0x408be1d0->(VT_BSTR),0x408be220->(VT_BSTR),0x408be210)
0009:trace:heap:RtlAllocateHeap (0x4034,0002,0018): returning 42b4bfd0

VARIANT: VarCat: L"&H"+L"8000"=L"&H8000"
and so on

I know that color properties can have standard system values which start with &H8000...
But is this the reason? And why does this get into VarParseNumFromStr?

Thanks

bye  Fabi

System Error H80010108 (-2147417848)

[Fabian Cenedese]

Hi

Did I already mention what I think of VB?...

I try another VB program with an embedded ocx on wine and it gives
me a dialog with the above mentioned error message. Then it just quits.

After looking on the internet I found some explanation of this error:
Run-time error '-2147417848 (80010108)' automation error The object invoked has been 
disconnected from its clients.

But that doesn't tell me what's wrong. In the trace logs I can see it build
and display this message but nothing that would show what went wrong
before.

Does anybody know this error or its reasons?

Thanks

bye  Fabi

Re: LOCAL: Not enough space in GDI heap

[Fabian Cenedese]

At 16:39 09.02.2004 +, Huw D M Davies wrote:
>On Mon, Feb 09, 2004 at 05:03:40PM +0100, Fabian Cenedese wrote:
>> 
>> I hacked some more and need an advice. I changed font.cpp: CreateFontIndirectW
>> a bit. Instead of always allocating a new gdi object it has a list of already
>> allocated font objects and first tests if there was already a font allocated
>> with the same logical properties (LOGFONTW). If so it just returns the
>> existing HFONT and doesn't allocate a new one. With this change my
>> VB app with the many controls comes up and is almost usable. Some
>> fonts on the registers of the tab control look quite strange. But besides
>> that it works.
>> 
>> Now is this a reasonable change (apart from its hacky implementation
>> now :) ? Is the function CreateFontIndirect allowed to do something like
>> this? Are there more things I should test than just the ones in the
>> LOGFONTW struct? If anybody is interested in a screenshot (the
>> funny fonts go down by about 20 degrees :) just raise your hand.
>
>No, this isn't right.  You can convince yourself of this by a quick
>test program on Windows; initialize a LOGFONT and then call
>CreateFontIndirect twice, you'll get two different hfonts back.

My idea for caching the handles in CreateFontIndirect came from this:

GdiFont WineEngCreateFontInstance(DC *dc, HFONT hfont)
--snip--
if(ret->hfont == hfont && !memcmp(&ret->xform, &dc->xformWorld2Vport, 
offsetof(XFORM, eDx))) {

Here it not only tests the properties but also the handles. So if the handles
are different (as they are now from CreateFontIndirect) it will always
create a new font. But removing this check didn't help either :)

>I suspect your leak happens in the olefont implementation.  You want
>to check that each hfont is destroyed when the IOleFont interface is
>released.

When are the fonts released? If a control creates a font and uses it until
the dialog gets closed it doesn't help much. There will still be too many
fonts while running. Or should the control create a font every time it has
to draw anything and will release it again after? I can see releases but
the reference counter never reaches 0 until the end of the program where
all remaining fonts are cleaned up.

Sorry for asking, I don't know much about ole, fonts and stuff :)

bye   Fabi

Re: LOCAL: Not enough space in GDI heap

[Fabian Cenedese]

>> I hacked some more and need an advice. I changed font.cpp: CreateFontIndirectW
>> a bit. Instead of always allocating a new gdi object it has a list of already
>> allocated font objects and first tests if there was already a font allocated
>> with the same logical properties (LOGFONTW). If so it just returns the
>> existing HFONT and doesn't allocate a new one. With this change my
>> VB app with the many controls comes up and is almost usable. Some
>> fonts on the registers of the tab control look quite strange. But besides
>> that it works.
>> 
>> Now is this a reasonable change (apart from its hacky implementation
>> now :) ? Is the function CreateFontIndirect allowed to do something like
>> this? Are there more things I should test than just the ones in the
>> LOGFONTW struct? If anybody is interested in a screenshot (the
>> funny fonts go down by about 20 degrees :) just raise your hand.
>
>No, this isn't right.  You can convince yourself of this by a quick
>test program on Windows; initialize a LOGFONT and then call
>CreateFontIndirect twice, you'll get two different hfonts back.
>
>I suspect your leak happens in the olefont implementation.  You want
>to check that each hfont is destroyed when the IOleFont interface is
>released.

I also sometimes had this in mind as I couldn't find OLEFontImpl_Release
calling OLEFontImpl_Destroy in my logs. The reference pointer never
seems to become 0. So I will have a look into this.

Thanks

bye  Fabi

Re: LOCAL: Not enough space in GDI heap

[Fabian Cenedese]

>>>If you work with Win2K/XP, you can use NTobjects a free tool from
>>>www.smidgeonsoft.com. It shows you for each process the number of each
>>>type of GDI objects, compare that with the number that you observe in
>>>your wine logs.
>>
>>That's a nice page, interesting looking tools. I tried it out and if the app is
>>running it has 39 fonts and the other items (Pen, Brush, Bitmap) even less.
>>So this looks like wine reserves unnecessarily too many fonts. I'll see if
>>I find something more.
>
>After fiddling around and creating some test programs I found that in wine
>a font is created for every control. Even a simple dialog with just four labels
>or textboxes in it will have 4 times a MS Sans Serif font. So this looks like
>another problem concerning wine and VB (Man, I hate this VB...). On Windows
>it uses only one font MS Sans Serif. As my original application which I want to
>make work uses many dialogs and controls it's now obvious why it runs
>out of GDI memory.
>
>I'm now trying to find out who decides if a new font has to be created or
>if an old one can be used. If anyone knows about this (in VB) please
>let me know.

I hacked some more and need an advice. I changed font.cpp: CreateFontIndirectW
a bit. Instead of always allocating a new gdi object it has a list of already
allocated font objects and first tests if there was already a font allocated
with the same logical properties (LOGFONTW). If so it just returns the
existing HFONT and doesn't allocate a new one. With this change my
VB app with the many controls comes up and is almost usable. Some
fonts on the registers of the tab control look quite strange. But besides
that it works.

Now is this a reasonable change (apart from its hacky implementation
now :) ? Is the function CreateFontIndirect allowed to do something like
this? Are there more things I should test than just the ones in the
LOGFONTW struct? If anybody is interested in a screenshot (the
funny fonts go down by about 20 degrees :) just raise your hand.

Maybe the caching needs to be done at another place. I have already
seen the GdiFontList in freetype.c. But then it's already too late (and
only works for ttf I guess). Another possibility may be to create the
font but then free it again if a similar is found.

Thanks

bye  Fabi

Re: LOCAL: Not enough space in GDI heap

[Fabian Cenedese]

>>> Now is this an error in my application (VB6 with lots of controls and ocx's)
>>> or one in wine? Does my app really create so many fonts or should each
>>> only appear once in this list because they're all the same? They do have
>>> different handles/addresses but that could be wine too. Of course it works
>>> on Windows but that could just be pure luck :)
>>> Is there some way to tell on Windows if it really uses so much GDI heap?
>>> Being a VB app it's not that easy to debug low-level.
>>
>>If you work with Win2K/XP, you can use NTobjects a free tool from
>>www.smidgeonsoft.com. It shows you for each process the number of each
>>type of GDI objects, compare that with the number that you observe in
>>your wine logs.
>
>That's a nice page, interesting looking tools. I tried it out and if the app is
>running it has 39 fonts and the other items (Pen, Brush, Bitmap) even less.
>So this looks like wine reserves unnecessarily too many fonts. I'll see if
>I find something more.

After fiddling around and creating some test programs I found that in wine
a font is created for every control. Even a simple dialog with just four labels
or textboxes in it will have 4 times a MS Sans Serif font. So this looks like
another problem concerning wine and VB (Man, I hate this VB...). On Windows
it uses only one font MS Sans Serif. As my original application which I want to
make work uses many dialogs and controls it's now obvious why it runs
out of GDI memory.

I'm now trying to find out who decides if a new font has to be created or
if an old one can be used. If anyone knows about this (in VB) please
let me know.

Thanks

bye  Fabi

Bug compatible?

[Fabian Cenedese]

Hi

Looking for something else I found this in wine/objects/font.c:

GetTextExtentPointA/W:
TRACE("not bug compatible.");

As funny as it is it doesn't say that much. Is this referring to a bug
in Windows? And in what way not compatible? Maybe there should
be some comment explaining it.

Thanks

bye  Fabi

Wrong short filenames instead of long ones

[Fabian Cenedese]

Hi

I'm trying to find a file copy tool which works on windows as well as wine.
I tried several and this looked promising:

ftp://ftp.simtel.net/pub/simtelnet/msdos/fileutil/cc108dos.zip

On Windows it copied all files without problems and kept the long filenames
even if the name implies that it's DOS-only, but it worked fine on W2K.
But on wine the long names where all shortened to something like
CINO~E2H.CPP. So it doesn't look like normal DOS short names ...~1.cpp
but it's not the long name either. Can anybody try this out?

My wine (actual cvs) config is set to windows version nt40.

Thanks

bye  Fabi

Re: OLEPictureImpl_Load: fix for headerless pictures

[Fabian Cenedese]

At 12:58 06.02.2004 -0500, Kirill Smelkov wrote:
>On Fri, 6 Feb 2004, Fabian Cenedese wrote:
>
>[...]
>> >I can't help you until i see how your app is supposed to work.
>> >Please make sure the programm runs without (header[1]==0).
>>
>> That's the point, it doesn't work on wine in the current state. That's why
>> I try to fix wine. Use my patch (even if it's wrong for your progs) then
>> my app should come up and you can test what's going on.
>> This bug in wine prevents many VB apps from running on wine. And as
>> we have some of them I tried to fix it.
>
>Maybe i missed something (is so, i'm sorry), but where do i get your
>patches?

I sent it to wine-devel, but I can't access winehq at the moment (down?)
so here it is again. It's just jumping out if header [1] is 0 (which works
for me but I guess it's wrong for your programs).


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 -   1.30
+++ dlls/oleaut32/olepicture.c  29 Jan 2004 16:19:25 -
@@ -873,6 +873,9 @@
   hr=IStream_Read(pStm,header,8,&xread);
   if (hr || xread!=8) {
   FIXME("Failure while reading picture header (hr is %lx, nread is 
%ld).\n",hr,xread);
+  return hr;
+  }
+  if (header[1]==0) {
   return hr;
   }
   if (header[1] > statstg.cbSize.QuadPart) {/* Incorrect header, assume none. */

bye  Fabi

Re: LOCAL: Not enough space in GDI heap

[Fabian Cenedese]

At 17:42 05.02.2004 +0100, Rein Klazes wrote:
>> Now is this an error in my application (VB6 with lots of controls and ocx's)
>> or one in wine? Does my app really create so many fonts or should each
>> only appear once in this list because they're all the same? They do have
>> different handles/addresses but that could be wine too. Of course it works
>> on Windows but that could just be pure luck :)
>> Is there some way to tell on Windows if it really uses so much GDI heap?
>> Being a VB app it's not that easy to debug low-level.
>
>If you work with Win2K/XP, you can use NTobjects a free tool from
>www.smidgeonsoft.com. It shows you for each process the number of each
>type of GDI objects, compare that with the number that you observe in
>your wine logs.

That's a nice page, interesting looking tools. I tried it out and if the app is
running it has 39 fonts and the other items (Pen, Brush, Bitmap) even less.
So this looks like wine reserves unnecessarily too many fonts. I'll see if
I find something more.

Thanks.

bye  Fabi

Re: OLEPictureImpl_Load: fix for headerless pictures

[Fabian Cenedese]

>> Where did you disable it? My patch or yours? With my patch it should
>> never even get to try to call CreateIcon (which fails). So either the
>> field is not 0 or you don't jump out.
>
>I juste removed my header[1]==1, so you can say i rejected my patch.
>
>> >MessageBox with
>> >"Failed to load control 'SSTab' from TABCTL32.OCX. Your version of
>> >TABCTL32.OCX is outdated"
>>
>> This is the error I wanted to eliminate, just look for my postings with
>> SSTAB in the subject in the last two months :)
>> When I jump out if header[1] is 0 then I don't get this error anymore
>and
>> VB programs with the SSTab control come up. But I only tried those
>> without icons as I assumed that those with icons don't have a 0 field.
>But they do have 0 field...
>
>I can't help you until i see how your app is supposed to work.
>Please make sure the programm runs without (header[1]==0).

That's the point, it doesn't work on wine in the current state. That's why
I try to fix wine. Use my patch (even if it's wrong for your progs) then
my app should come up and you can test what's going on.
This bug in wine prevents many VB apps from running on wine. And as
we have some of them I tried to fix it.

bye  Fabi

Re: LOCAL: Not enough space in GDI heap

[Fabian Cenedese]

>When trying to run a program I get these messages:
>
>err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
>trace:ole:OLEFontImpl_get_hFont Returning (nil)
>wine: Unhandled exception (thread 0009), starting debugger...
>
>I had a look at this LOCAL_GetBlock function. There is already code
>with some FIXME comments, but it's all #ifdef 0'd out. So that means
>it's not tested or not even supposed to work. Is there something else
>I could do to increase my GDI heap?

I think that wouldn't help much. I made more traces to find this:

trace:font:DumpGdiFontList -- gdiFont Cache --
trace:gdi:GetObjectW 0xd82 92 0x408bf718
trace:gdi:GDI_GetObjPtr (0xd82): enter 2
trace:gdi:GDI_ReleaseObj (0xd82): leave 2
trace:font:DumpGdiFontList gdiFont=0x40383250  hfont=0xd82 (L"MS Sans Serif")
trace:gdi:GetObjectW 0xa6 92 0x408bf718
trace:gdi:GDI_GetObjPtr (0xa6): enter 2
trace:gdi:GDI_ReleaseObj (0xa6): leave 2
trace:font:DumpGdiFontList gdiFont=0x40378f30  hfont=0xa6 (L"System")

Looks good, two fonts, but then later:

trace:font:DumpGdiFontList -- gdiFont Cache --
trace:gdi:GetObjectW 0x14c6 92 0x408bf718
trace:gdi:GDI_GetObjPtr (0x14c6): enter 2
trace:gdi:GDI_ReleaseObj (0x14c6): leave 2
trace:font:DumpGdiFontList gdiFont=0x40385938  hfont=0x14c6 (L"MS Sans Serif")
trace:gdi:GetObjectW 0xd82 92 0x408bf718
trace:gdi:GDI_GetObjPtr (0xd82): enter 2
trace:gdi:GDI_ReleaseObj (0xd82): leave 2
trace:font:DumpGdiFontList gdiFont=0x40383250  hfont=0xd82 (L"MS Sans Serif")
trace:gdi:GetObjectW 0xa6 92 0x408bf718
trace:gdi:GDI_GetObjPtr (0xa6): enter 2
trace:gdi:GDI_ReleaseObj (0xa6): leave 2
trace:font:DumpGdiFontList gdiFont=0x40378f30  hfont=0xa6 (L"System")

Already two times MS Sans Serif...


trace:font:DumpGdiFontList -- gdiFont Cache --
trace:gdi:GetObjectW 0x23d6 92 0x408bf70c
trace:gdi:GDI_GetObjPtr (0x23d6): enter 2
trace:gdi:GDI_ReleaseObj (0x23d6): leave 2
trace:font:DumpGdiFontList gdiFont=0x403b06f8  hfont=0x23d6 (L"MS Sans Serif")
...
all in all 32 fonts MS Sans Serif.
...
trace:gdi:GetObjectW 0xa6 92 0x408bf70c
trace:gdi:GDI_GetObjPtr (0xa6): enter 2
trace:gdi:GDI_ReleaseObj (0xa6): leave 2
trace:font:DumpGdiFontList gdiFont=0x40378f30  hfont=0xa6 (L"System")



trace:font:DumpGdiFontList -- gdiFont Cache --
trace:gdi:GetObjectW 0x2dfe 92 0x408bf6e8
trace:gdi:GDI_GetObjPtr (0x2dfe): enter 2
trace:gdi:GDI_ReleaseObj (0x2dfe): leave 2
trace:font:DumpGdiFontList gdiFont=0x403dabf8  hfont=0x2dfe (L"MS Sans Serif")
...
32 Fonts MS Sans Serif
...
trace:gdi:GetObjectW 0x23e6 92 0x408bf6e8
trace:gdi:GDI_GetObjPtr (0x23e6): enter 2
trace:gdi:GDI_ReleaseObj (0x23e6): leave 2
trace:font:DumpGdiFontList gdiFont=0x403a3b80  hfont=0x23e6 (L"Arial")
trace:gdi:GetObjectW 0x23d6 92 0x408bf6e8
trace:gdi:GDI_GetObjPtr (0x23d6): enter 2
trace:gdi:GDI_ReleaseObj (0x23d6): leave 2
trace:font:DumpGdiFontList gdiFont=0x403b06f8  hfont=0x23d6 (L"MS Sans Serif")
...
another 32 Fonts MS Sans Serif
...
trace:gdi:GetObjectW 0xa6 92 0x408bf6e8
trace:gdi:GDI_GetObjPtr (0xa6): enter 2
trace:gdi:GDI_ReleaseObj (0xa6): leave 2
trace:font:DumpGdiFontList gdiFont=0x40378f30  hfont=0xa6 (L"System")


Or some time much later even this:

trace:font:DumpGdiFontList -- gdiFont Cache --
trace:gdi:GetObjectW 0xf48e 92 0x408bf6e8
trace:gdi:GDI_GetObjPtr (0xf48e): enter 2
trace:gdi:GDI_ReleaseObj (0xf48e): leave 2
trace:font:DumpGdiFontList gdiFont=0x47d7c160  hfont=0xf48e (L"MS Sans Serif")
...
180 Fonts MS Sans Serif
...
trace:gdi:GetObjectW 0x9a82 92 0x408bf6e8
trace:gdi:GDI_GetObjPtr (0x9a82): enter 2
trace:gdi:GDI_ReleaseObj (0x9a82): leave 2
trace:font:DumpGdiFontList gdiFont=0x4400be90  hfont=0x9a82 (L"Courier")
trace:gdi:GetObjectW 0x9a7a 92 0x408bf6e8
trace:gdi:GDI_GetObjPtr (0x9a7a): enter 2
trace:gdi:GDI_ReleaseObj (0x9a7a): leave 2
trace:font:DumpGdiFontList gdiFont=0x4400a678  hfont=0x9a7a (L"MS Sans Serif")
...
another 208 Fonts MS Sans Serif
...
trace:gdi:GetObjectW 0x23e6 92 0x408bf6e8
trace:gdi:GDI_GetObjPtr (0x23e6): enter 2
trace:gdi:GDI_ReleaseObj (0x23e6): leave 2
trace:font:DumpGdiFontList gdiFont=0x403a3b80  hfont=0x23e6 (L"Arial")
trace:gdi:GetObjectW 0x23d6 92 0x408bf6e8
trace:gdi:GDI_GetObjPtr (0x23d6): enter 2
trace:gdi:GDI_ReleaseObj (0x23d6): leave 2
trace:font:DumpGdiFontList gdiFont=0x403b06f8  hfont=0x23d6 (L"MS Sans Serif")
...
another 32 Fonts MS Sans Serif
...
trace:gdi:GetObjectW 0xa6 92 0x408bf6e8
trace:gdi:GDI_GetObjPtr (0xa6): enter 2
trace:gdi:GDI_ReleaseObj (0xa6): leave 2
trace:font:DumpGdiFontList gdiFont=0x40378f30  hfont=0xa6 (L"System")


Now is this an error in my application (VB6 with lots of controls and ocx's)
or one in wine? Does my app really create so many fonts or should each
only appear once in this list because they're all the same? They do have
different handles/addresses but that could be wine too. Of course it works
on Windows but that could just be pure luck :)
Is there some way to tell on Windows if 

LOCAL: Not enough space in GDI heap

[Fabian Cenedese]

Hi

When trying to run a program I get these messages:

trace:font:GetTextMetricsW text metrics:
Weight = 400 FirstChar = 32  AveCharWidth = 6
Italic =   0 LastChar = 65532MaxCharWidth = 35
UnderLined = 0   DefaultChar = 0 Overhang = 0
StruckOut = 0BreakChar = 32  CharSet = 0
PitchAndFamily = 27

InternalLeading = 3
Ascent = 13
Descent = 3
Height = 16
trace:font:X11DRV_SelectFont hdc=0x74, hfont=0xa6
trace:font:X11DRV_SelectFont dc->gdiFont = 0x40378f28
trace:ole:OLEFontImpl_SetRatio (0x47d85a60)->(96, 2540)
trace:ole:OLEFontImpl_get_hFont (0x47d85a60)->(0x408bf0bc)
trace:ole:OLEFontImpl_get_Size (0x47d85a60)->(0x408bf034)
err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes
trace:ole:OLEFontImpl_get_hFont Returning (nil)
wine: Unhandled exception (thread 0009), starting debugger...

I had a look at this LOCAL_GetBlock function. There is already code
with some FIXME comments, but it's all #ifdef 0'd out. So that means
it's not tested or not even supposed to work. Is there something else
I could do to increase my GDI heap?

Thanks

bye  Fabi

Re: OLEPictureImpl_Load: fix for headerless pictures

[Fabian Cenedese]

>> >Then what type of picture it is?
>> >
>> >0x4947  GIF
>> >0xd8ff  JPEG
>> >0x4d42  BMP
>> >0x  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.
>
>It's probably some ole-storage magic. Don't know as i have no clue on how
>ole works at all :)

Neither do I :)

>> 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.
>
>Fabi,
>
>I temporarly disable checking for (header[1]==0). even in such case your
>test-case doesn't start:
>fixme:ole:CoRegisterMessageFilter stub
>fixme:ole:OleLoadPictureEx
>(0x418ae294,774,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x4075fb08),
>partially implemented.
>fixme:ole:OleLoadPictureEx
>(0x418ae294,774,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x4075fad8),
>partially implemented.
>fixme:ole:SPCF_CreateInstance
>(0x40acdbc8,(nil),{7bf80980-bf32-101a-8bbb-00aa00300cab},0x402313a4),
>creating stdpic with PICTYPE_NONE.
>fixme:ole:SPCF_CreateInstance
>(0x40acdbc8,(nil),{7bf80980-bf32-101a-8bbb-00aa00300cab},0x40231aac),
>creating stdpic with PICTYPE_NONE.
>fixme:ole:OLEPictureImpl_Load CreateIcon failed.
>fixme:ole:OLEPictureImpl_Destroy Unsupported type 0 - unable to delete
>fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.

Where did you disable it? My patch or yours? With my patch it should
never even get to try to call CreateIcon (which fails). So either the field
is not 0 or you don't jump out.

>and then
>
>MessageBox with
>"Failed to load control 'SSTab' from TABCTL32.OCX. Your version of
>TABCTL32.OCX is outdated"
>
>Does it work at all?

This is the error I wanted to eliminate, just look for my postings with SSTAB
in the subject in the last two months :)
When I jump out if header[1] is 0 then I don't get this error anymore and
VB programs with the SSTab control come up. But I only tried those
without icons as I assumed that those with icons don't have a 0 field.

>If so, then we probably should figure out whethere there are some
>ole-storage magic present and chek for them when decidign whether to look at 
>header[1] and how to interpret it.

This is definitely above me. Maybe some guru can help here. Who's
a pro in ole pictures? Picking anyone's pride? :)

bye  Fabi

Re: ListView painting (was Re: Mouse up vs Mouse click)

[Fabian Cenedese]

>I think there are still problems with that patch because, in emule
>when I change the size of a column, the selected row is not repainted
>correctly, only some area of it are.
>The style is fullrowselect and ownerdraw.
>
>Only the new space of the column whose size has increased is repainted
>correctly.

Do you already had that error before this patch? Because this was in the
function HitTest, used e.g. when you click with the mouse on the list.
But I don't think that has anything to do with resizing. But I didn't try it. I
also saw that the repainting of the other columns isn't always correct,
even without these styles. But that was not the goal of this patch.

bye  Fabi

Re: OLEPictureImpl_Load: fix for headerless pictures

[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
>0x  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

buffer too small for currency

[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

Re: OLEPictureImpl_Load: fix for headerless pictures

[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

Re: OLEPictureImpl_Load: fix for headerless pictures

[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

Re: OLEPictureImpl_Load: fix for headerless pictures

[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 -   1.30
>+++ dlls/oleaut32/olepicture.c  1 Feb 2004 12:35:41 -
>@@ -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

Re: ListView painting (was Re: Mouse up vs Mouse click)

[Fabian Cenedese]

At 10:12 02.02.2004 -0500, Dimitrie O. Paun wrote:
>I don't think behaviour in the LVS_OWNERDRAWFIXED case is explicitly documented,
>but I think it should behave as in the LVS_EX_FULLROWSELECT case. In other words,
>I think your patch is correct, please submit it to wine-patches.

Done. Thanks :)

bye  Fabi

Re: ListView painting (was Re: Mouse up vs Mouse click)

[Fabian Cenedese]

>>The mouse tracking in listview happens in the LISTVIEW_TrackMouse()
>>function, which seems correct. It is getting called from only one
>>place (in LISTVIEW_LButtonDown()) so a few print statements there
>>would be nice to see that (1) it is being called, and (2) that it
>>doesn't exit prematurely.
>
>I made a test and added a printf message in the loop of TrackMouse.
>When I hold the mouse button in the first column I see hundreds of
>these message pass by. But when I press on another column I don't
>even see it enter the whole function TrackMouse, not to mention the
>message from the loop. In LISTVIEW_LButtonDown the nItem is -1,
>so it thinks that no item is selected and skips most of the code.
>
>I'm still looking at logs. But I also thought that LISTVIEW_HitTest
>gave wrong results for other columns (LVHT_NOWHERE) but I
>still need to look further. But that might go along with the listview
>thinking that no item is selected.

Getting closer. I now know where the problem is though I don't know
the solution. It's in this function:

static INT LISTVIEW_HitTest(LISTVIEW_INFO *infoPtr, LPLVHITTESTINFO lpht, BOOL 
subitem, BOOL select)
{
-- snip--

if (select && !(uView == LVS_REPORT && (infoPtr->dwLvExStyle & 
LVS_EX_FULLROWSELECT)))
{
if (uView == LVS_REPORT)
{
UnionRect(&rcBounds, &rcIcon, &rcLabel);
UnionRect(&rcBounds, &rcBounds, &rcState);
}

if (!PtInRect(&rcBounds, opt)) iItem = -1;
}

return lpht->iItem = iItem;
}

In the end is this piece of code. What's the intention of it? If my ListCtrl
is LVS_EX_FULLROWSELECT it never enters this code, if my ListCtrl is
not then it enters here but does wrong stuff. If I comment out this code
completely all works fine because right before this the item and subitem
are found correctly.

I have made a little test program I could mail to anyone who's interested
in this. It's just a simple dialog with a list control where you can switch
on and off the OWNERDRAWFIXED and FULLROWSELECT. With the
current wine implementation and FULLROWSELECT set it works
ok (with and without ownerdraw). Without fullrow but with ownerdraw
it gives the errors I've been looking at for weeks. Commenting out the
above code makes it work but then the normal mode (both flags off)
has repainting issues, the items in second or more column stay
selected when moving to another row. But then even the current
implementation is alike.
It could also be that some other places need changes to make all
variations work. But that's again above my head. I tried adding the
ownerdraw flag to this code. Works in my case.

bye  Fabi


Index: wine/dlls/comctl32/listview.c
===
RCS file: /home/wine/wine/dlls/comctl32/listview.c,v
retrieving revision 1.380
diff -u -r1.380 listview.c
--- wine/dlls/comctl32/listview.c   10 Dec 2003 00:37:14 -  1.380
+++ wine/dlls/comctl32/listview.c   2 Feb 2004 14:09:16 -
@@ -5980,7 +5980,8 @@
}
 }

-if (select && !(uView == LVS_REPORT && (infoPtr->dwLvExStyle & 
LVS_EX_FULLROWSELECT)))
+if (select && !(uView == LVS_REPORT && ((infoPtr->dwLvExStyle & 
LVS_EX_FULLROWSELECT)
+   || (infoPtr->dwStyle & LVS_OWNERDRAWFIXED
 {
 if (uView == LVS_REPORT)
 {

Re: ListView painting (was Re: Mouse up vs Mouse click)

[Fabian Cenedese]

>On January 30, 2004 07:55 am, Fabian Cenedese wrote:
>> I think I already found the (apparent) difference in the events, the
>> (not) hanging in the OnLButtonDown. I need to find out why it doesn't
>> stay in there and if it's in listview, message, events...
>
>The mouse tracking in listview happens in the LISTVIEW_TrackMouse()
>function, which seems correct. It is getting called from only one
>place (in LISTVIEW_LButtonDown()) so a few print statements there
>would be nice to see that (1) it is being called, and (2) that it
>doesn't exit prematurely.

I made a test and added a printf message in the loop of TrackMouse.
When I hold the mouse button in the first column I see hundreds of
these message pass by. But when I press on another column I don't
even see it enter the whole function TrackMouse, not to mention the
message from the loop. In LISTVIEW_LButtonDown the nItem is -1,
so it thinks that no item is selected and skips most of the code.

I'm still looking at logs. But I also thought that LISTVIEW_HitTest
gave wrong results for other columns (LVHT_NOWHERE) but I
still need to look further. But that might go along with the listview
thinking that no item is selected.

Thanks for your hints, give me new ideas.

bye  Fabi

Re: ListView painting (was Re: Mouse up vs Mouse click)

[Fabian Cenedese]

>> That was my weak try to explain what I see :)
>> Ok, again in short what happens: I can click on a cell in the first column,
>> it gets selected, I can release the mouse button, everything fine.
>> But when I press on a cell in another column it shortly gets selected
>> and immediately the selection again disappears, even while still
>> holding the mouse button. The logical selection seems to be ok
>> as I can move it to another cell with the cursor keys (and it strangely
>> stays there unlike if done so with the mouse).
>
>OK, so it seems that your app uses the listview in LVS_REPORT mode,
>and that it wants to make it bahave like a spreadsheet (that is,
>you want to be able to individually select any cell from the
>row/column matrix of the listview). Hence the OWNERDRAW, as by
>default a listview in REPORT more can either select the cell in
>the first column or the entire row.

Hmm... that might be a thing to try too as it works for the first column.
That would be LVS_EX_FULLROWSELECT... Nah, didn't change
anything except some flicker.

>Now, I haven't used MFC before, so I don't know if this behaviour
>is done in your app or in MFC code. If it's in your app, it should
>be simple enough to add some print statements to figure out the
>paint order and to confirm/ruleout this theory. If it's done in
>MFC, I'm afraid you'll need to get creative, 'cause I can't help.

Of course some is application code as the listcontrol doesn't
behave like that. But it doesn't need that much as there are already
a lot of useful functions (SubItemHitTest, DrawItem...) I just need
to keep an index of the selected column in addition to the already
exisiting SelectedRow. And the painting of just this one cell instead
of the whole line. The bigger stuff is to include other controls (text,
combo) in the cells.

>But the problem seems to be in the order of events (or some missing
>notifications). Print statements are what you want: they'll help you
>figure out (1) if you get all required notifications, and (2) if they
>arrive in the right order.

I think I already found the (apparent) difference in the events, the 
(not) hanging in the OnLButtonDown. I need to find out why it doesn't
stay in there and if it's in listview, message, events...

Thanks

bye  Fabi

Re: OLEPictureImpl_Load CreateIcon failed

[Fabian Cenedese]

>>I'm still on the VB SSTab problem as described here:
>>
>>http://www.winehq.org/hypermail/wine-devel/2003/12/0157.html
>
>I now know that it works if there are icons (property Picture) assigned
>to the single tabs in the TabCtrl. But if the icons are missing, wine
>goes woo. So either wine shouldn't try to create pictures if there
>aren't any, or it should cope with failing CreateIcon calls. I guess
>the first case would be better.

May not be the right solution but makes an SSTab without icons
come up.

bye  Fabi


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 -   1.30
+++ dlls/oleaut32/olepicture.c  29 Jan 2004 16:19:25 -
@@ -873,6 +873,9 @@
   hr=IStream_Read(pStm,header,8,&xread);
   if (hr || xread!=8) {
   FIXME("Failure while reading picture header (hr is %lx, nread is 
%ld).\n",hr,xread);
+  return hr;
+  }
+  if (header[1]==0) {
   return hr;
   }
   if (header[1] > statstg.cbSize.QuadPart) {/* Incorrect header, assume none. */

Re: OLEPictureImpl_Load CreateIcon failed

[Fabian Cenedese]

>I'm still on the VB SSTab problem as described here:
>
>http://www.winehq.org/hypermail/wine-devel/2003/12/0157.html
>
>I looked further into this to find out what happens with this picture
>stuff. I found out that it fails in this function (from olepicture.c):
>
> * OLEPictureImpl_IPersistStream_Load (IUnknown)
> * Loads the binary data from the IStream. Starts at current position.
> * Currently implemented: BITMAP, ICON, JPEG.
>static HRESULT WINAPI OLEPictureImpl_Load(IPersistStream* iface,IStream*pStm) {
>
>It first reads the picture size from the stream and reads the picture
>properties and data. This works sometimes, I can see it creating
>e.g. 32x32 pictures for icons. But in this error I have it always
>fails due to the reported picture data size of zero. So it doesn't
>read any picture properties from the stream and tries to create
>a picture with 0x0 dimensions. Obviously this fails.
>But now I can't find out where this comes from. What is this stream
>where it wants to read data from? In what source file is this implemented?
>The used IStream_Load is just a macro. What could have gone wrong
>earlier that this picture size is now zero? Maybe the stream is ok but
>wine wants to create more pictures than there are?

Another one of my threads :)

I now know that it works if there are icons (property Picture) assigned
to the single tabs in the TabCtrl. But if the icons are missing, wine
goes woo. So either wine shouldn't try to create pictures if there
aren't any, or it should cope with failing CreateIcon calls. I guess
the first case would be better.

bye  Fabi

Re: ListView painting (was Re: Mouse up vs Mouse click)

[Fabian Cenedese]

At 08:27 29.01.2004 -0500, Dimitrie O. Paun wrote:
>On January 29, 2004 08:08 am, Fabian Cenedese wrote:
>> Understandable. Any hints how I could continue? Where to look at?
>
>I don't think I understand this bit. Care to explain it again?
>
>  "So for me it looks like this: When I click in a cell it gets invalidated
>   and painted selected. But if the cell is not in the first row the first
>   column (or the whole line) gets invalidated and repainted too, therefore
>   erasing the already painted selection."

Another idea: When a line changes it is completely invalidated and
repainted without any selection. The the new cell is painted again
with selection. So what if these two events are in wrong order? My
cell gets selected and immediately loses it again. And that's maybe
what happens as "it" (main thread?) doesn't wait in the OnLButtonDown
as it does for the first column cells.
Of course it's not just that simple as I made a test with a simple
ownerdrawn listcontrol which of course worked. So it must be more
in my app that interferes. Could it be that the listview is inside a ocx?
Different event handling?

bye  Fabi

Re: ListView painting (was Re: Mouse up vs Mouse click)

[Fabian Cenedese]

At 08:27 29.01.2004 -0500, Dimitrie O. Paun wrote:
>On January 29, 2004 08:08 am, Fabian Cenedese wrote:
>> Understandable. Any hints how I could continue? Where to look at?
>
>I don't think I understand this bit. Care to explain it again?
>
>  "So for me it looks like this: When I click in a cell it gets invalidated
>   and painted selected. But if the cell is not in the first row the first
>   column (or the whole line) gets invalidated and repainted too, therefore
>   erasing the already painted selection."

That was my weak try to explain what I see :)
Ok, again in short what happens: I can click on a cell in the first column,
it gets selected, I can release the mouse button, everything fine.
But when I press on a cell in another column it shortly gets selected
and immediately the selection again disappears, even while still
holding the mouse button. The logical selection seems to be ok
as I can move it to another cell with the cursor keys (and it strangely
stays there unlike if done so with the mouse).
So if only the visual display is wrong I was looking for an explanation
with the paint events. The cell is set selected and then the whole
line invalidated (as it is ownerdrawn). Maybe in Windows only the
Invalidate/Update cause the line to be repainted whereas in wine
already the SetItem will cause a first Update and then the Invalidate
a second one. But then again it should just flicker a bit but not
completely disappear...
Btw, the hanging in the CListCtrl::OnLButtonDown I mentioned
is also in wine for the first column (maybe that's why this works).
But for the other columns it just rushes through.

bye  Fabi

Re: ListView painting (was Re: Mouse up vs Mouse click)

[Fabian Cenedese]

At 07:54 29.01.2004 -0500, Dimitrie O. Paun wrote:
>On January 29, 2004 06:27 am, Fabian Cenedese wrote:
>> Does anybody know about the handling of mouse events in the listview?
>> Is this a bug or just not implemented yet (I've seen the comment in the
>> beginning of listview.c :) ?
>
>The comment is wrong and needs updating. Huw Davies added drag&drop
>support some time ago (2003/11/03). I'd love to be more helpful on
>this matter, but I'm out of bandwidth at the moment...

Understandable. Any hints how I could continue? Where to look at?

Thanks

bye  Fabi

ListView painting (was Re: Mouse up vs Mouse click)

[Fabian Cenedese]

>>>The misbehaving app uses a ownerdrawn, CListCtrl-derived list. When
>>>I click on a cell not in the first column the cell gets selected. But on
>>>wine I can see that the selection flashes shortly and disappears right
>>>again (Surprisingly it works when I click in the first column. As my
>>>application uses the same code for all columns it must be something
>>>else.). After putting some debug messages in my code I found that
>>>on Windows after the left-button-down event a left-button-click event
>>>is generated, no matter how long I hold the button before releasing.
>>>On wine there is no click event but a mouse up event. And the cell
>>>flashes even when I hold the button, so it's not the releasing itself
>>>that clears the selection.
>
>I tried again to find this problem. I couldn't find any difference in how the
>mouse messages are generated/handled between the two cases (clicking
>on first column/not first column). I now start to think that it's more a focus
>problem. If the focus is immediately shifted away after getting it it might
>look like the flashing cell I have now. To find out more about the focus
>I made some traces with +win.
>
>This is from clicking on the second column (doesn't work). Note
>the additional BeginPaint in the middle and the different
>paint flags:

(snip)

As nobody is participating I need to reply to my own posts :)

I may be getting closer. My assumptions about mouse handling or
focus seem both wrong. The cell gets activated and stays like that,
it's just not visible. But when I move with cursor keys the (invisible)
selection moves from the clicked cell to the next cell (and is now
visible).
So for me it looks like this: When I click in a cell it gets invalidated
and painted selected. But if the cell is not in the first row the first
column (or the whole line) gets invalidated and repainted too, therefore
erasing the already painted selection.


 From my code of the derived list control:

void CMyListCtrl::OnLButtonDown(UINT nFlags, CPoint point) 
{
LVHITTESTINFO ht;
ht.pt = point;
SubItemHitTest(&ht);

m_CurSubItem = IndexToOrder(ht.iSubItem);

if(ht.iItem!=-1)
{
CHeaderCtrl* pHeader = GetHeaderCtrl();

//set first selected and focus state
SetItem(ht.iItem, 0, LVIF_STATE, NULL, 0, LVIS_SELECTED | 
LVIS_FOCUSED, LVIS_SELECTED | LVIS_FOCUSED, 0);

//update row anyway for selection bar
CRect rc;
GetItemRect(ht.iItem, rc, LVIR_BOUNDS);
InvalidateRect(rc);
UpdateWindow();
} 

//following line is used for drag&drop support. I don't know why!! Do it at 
the 
//end of this function because it hangs until mouse up message has proceed.
CListCtrl::OnLButtonDown(nFlags, point);
// test
AfxMessageBox("Released");
}


The comment in the end is not from me but it really is like that. The call stays
in there until I release the mouse button, no matter if on the same cell or
somewhere else (as it says, for drag'n'drop). The test message box after
the call only comes up when I release the button. But on wine it immediately
pops up while still holding down the mouse button. I don't know how the
hanging is down on Windows but I think this is what mixes up my events
and why my cell doesn't stay painted selected. I'm still wondering though
why this isn't the same on the first column.

Does anybody know about the handling of mouse events in the listview?
Is this a bug or just not implemented yet (I've seen the comment in the
beginning of listview.c :) ?

Thanks

bye  Fabi

Re: Mouse up vs Mouse click

[Fabian Cenedese]

>>The misbehaving app uses a ownerdrawn, CListCtrl-derived list. When
>>I click on a cell not in the first column the cell gets selected. But on
>>wine I can see that the selection flashes shortly and disappears right
>>again (Surprisingly it works when I click in the first column. As my
>>application uses the same code for all columns it must be something
>>else.). After putting some debug messages in my code I found that
>>on Windows after the left-button-down event a left-button-click event
>>is generated, no matter how long I hold the button before releasing.
>>On wine there is no click event but a mouse up event. And the cell
>>flashes even when I hold the button, so it's not the releasing itself
>>that clears the selection.
>>
>>The control is a bit quirky with moving focus around and handling events
>>specially. But still it works on Windows :) Now I'm a bit lost how I can
>>debug this. +mouse didn't show anything usefull. I guess the
>>generating and sending of the events is done in the wineserver.
>> Could somebody explain me (or direct me to info) how this should work
>> in general? I mean even on Windows, when is something a click and
>> when a down/up or down/click? I know that a too slow double-click will
>> be two separate clicks, but I'm uncertain about the down/up events.
>
>This is what I know of it: the translations happen in the
>PeekMessage/GetMessage calls. If you follow the logic in
>windows/message.c, you see that the raw hardware messages are processed
>several times, and that a simple hardware message like mouse button up
>or down can lead to several others. Not only clicks/double clicks but
>also WM_SETCURSOR, WM_PARENTNORIFY, WM_ACTIVATE* and other (especially
>hooks) message that may come with a mouse click are generated there.

I tried again to find this problem. I couldn't find any difference in how the
mouse messages are generated/handled between the two cases (clicking
on first column/not first column). I now start to think that it's more a focus
problem. If the focus is immediately shifted away after getting it it might
look like the flashing cell I have now. To find out more about the focus
I made some traces with +win.

This is from clicking on the first column (works ok). In fact I have already
clicked before on a different line in the first column so the listbox surely already
has the focus:


trace:event:EVENT_ProcessEvent Got event ButtonPress for hwnd/window 0x2002c/2200016, 
GetFocus()=0x2002c
trace:cursor:send_mouse_event (8002,485,403)
trace:event:EVENT_ProcessEvent returns.
trace:win:WINPOS_WindowFromPoint scope 0x20029 485,403
trace:win:GetWindowRect hwnd 0x2002c (430,367)-(730,517)
trace:win:WINPOS_WindowFromPoint found child 0x2002c
trace:win:WIN_SetWindowLong 0x20029 0 0 3

trace:win:WIN_SetWindowLong 0x20029 0 0 3
trace:win:RedrawWindow 0x2002c ((nil)) rect 0,17-200,31 (nil) flags=0005
trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE
trace:win:RDW_UpdateRgnshwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0005]
trace:win:RDW_Paint hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0005]
trace:win:RedrawWindow 0x2002c (0x145a) rect 0,17-200,31 (nil) flags=0005
trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE
trace:win:RDW_UpdateRgnshwnd 0x2002c [0x145a] -> hrgn [0x145e], flags [0005]
trace:win:RDW_Paint hwnd 0x2002c [0x145a] -> hrgn [0x145e], flags [0005]
trace:win:RedrawWindow 0x2002c (0x145a) rect 0,31-200,45 (nil) flags=0005
trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE
trace:win:RDW_UpdateRgnshwnd 0x2002c [0x145a] -> hrgn [0x145e], flags [0005]
trace:win:RDW_Paint hwnd 0x2002c [0x145a] -> hrgn [0x145e], flags [0005]
trace:win:RedrawWindow 0x2002c (0x145a) rect 0,31-200,45 (nil) flags=0005
trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE
trace:win:RDW_UpdateRgnshwnd 0x2002c [0x145a] -> hrgn [0x145e], flags [0005]
trace:win:RDW_Paint hwnd 0x2002c [0x145a] -> hrgn [0x145e], flags [0005]
trace:win:RedrawWindow 0x2002c (0x145a) NULL 0,0-0,0 (nil) flags=0180
trace:win:dump_rdw_flags flags: RDW_ALLCHILDREN RDW_UPDATENOW
trace:win:RDW_UpdateRgnshwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0180]
trace:win:RDW_UpdateRgnshwnd 0x2002d [(nil)] -> hrgn [(nil)], flags [0180]
trace:win:RDW_Paint hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0180]
trace:win:begin_ncpaint hwnd 0x2002c [0x145a] ncf 0
trace:win:BeginPaint hdc = 0x74 box = (0,17 - 200,45)
trace:win:BeginPaint hdc = 0x74 box = (0,17 - 200,45), fErase = 0
trace:event:EVENT_ProcessEvent called.

trace:event:EVENT_ProcessEvent Got event ButtonRelease for hwnd/window 
0x2002c/2200016, GetFocus()=0x2002c
trace:cursor:send_mouse_event (8004,485,403)
trace:event:EVENT_ProcessEvent returns.
trace:win:WIN_SetWindowLong 0x20029 0 0 3
trace:event:EVENT_ProcessEvent called.


This is from clicking on the second column (doesn't work). Note
the additional BeginPaint in the middle and the different
paint flags:

trace:event:EVENT

OLEPictureImpl_Load CreateIcon failed

[Fabian Cenedese]

Hi

Looks like I'm quite busy today... or just don't know anything about wine :)

I'm still on the VB SSTab problem as described here:

http://www.winehq.org/hypermail/wine-devel/2003/12/0157.html

I looked further into this to find out what happens with this picture
stuff. I found out that it fails in this function (from olepicture.c):

 * OLEPictureImpl_IPersistStream_Load (IUnknown)
 * Loads the binary data from the IStream. Starts at current position.
 * Currently implemented: BITMAP, ICON, JPEG.
static HRESULT WINAPI OLEPictureImpl_Load(IPersistStream* iface,IStream*pStm) {

It first reads the picture size from the stream and reads the picture
properties and data. This works sometimes, I can see it creating
e.g. 32x32 pictures for icons. But in this error I have it always
fails due to the reported picture data size of zero. So it doesn't
read any picture properties from the stream and tries to create
a picture with 0x0 dimensions. Obviously this fails.
But now I can't find out where this comes from. What is this stream
where it wants to read data from? In what source file is this implemented?
The used IStream_Load is just a macro. What could have gone wrong
earlier that this picture size is now zero? Maybe the stream is ok but
wine wants to create more pictures than there are?

Thanks for any pointers.

bye  Fabi

Re: DllOverride for ocx?

[Fabian Cenedese]

>Fabian Cenedese wrote:
>>I have a ocx which works better with a native dll. But there are also other
>>apps which work worse if this dll is set to native by default. OK, so I add
>>a setting for the application which uses the ocx. Works. But there are
>>many apps that use this ocx and the customer could even make his own.
>>So it would be nice if I could have a dll override setting for just the ocx.
>>Is this technically possible at all? Or is the app-level the only one for
>>overrides? (I know, fixing wine would be even better, but I don't have the
>>time nor the knowledge. )-: But I keep trying whenever I can :)

At 12:32 27.01.2004 +0200, Boaz Harrosh wrote:
One hack you can do, If you have the Code for the OCX, is change the dll's name and 
compile against the new name.
Now the OCX relyes on one dll and the rest of the code on another you can even run 
with two different dlls at the same time.
Which is part of an answer to your original Q. What if One dll asks for "Native" while 
a second one asks for "builtin"? you see my point.
(If you do not have Source Code for the OCX you will have to HEX patch the OCX's 
import table. Not very easy to do)

I do have the source code and renaming the dll is a nice idea. However
I don't think that copying and renaming a Windows dll is a good thing :)
I already thought that it wouldn't be possible as an embedded ocx will
use the same dlls as the exe. So I will continue finding out what goes
wrong with the wine dll. My next question is already coming up :)

Thanks.

bye  Fabi

DllOverride for ocx?

[Fabian Cenedese]

Hi

I have a ocx which works better with a native dll. But there are also other
apps which work worse if this dll is set to native by default. OK, so I add
a setting for the application which uses the ocx. Works. But there are
many apps that use this ocx and the customer could even make his own.
So it would be nice if I could have a dll override setting for just the ocx.
Is this technically possible at all? Or is the app-level the only one for
overrides? (I know, fixing wine would be even better, but I don't have the
time nor the knowledge. )-: But I keep trying whenever I can :)

bye  Fabi

NtSetThreadExecutionState

[Fabian Cenedese]

Hi

(Message bounced the first so I try again.)

   - The following addresses had permanent fatal errors -
"|spamscan /var/lib/mailman/mail/wrapper-hq post wine-devel"
(reason: User unknown)
(expanded from: <[EMAIL PROTECTED]>)

   - Transcript of session follows -
550 5.1.1 "|spamscan /var/lib/mailman/mail/wrapper-hq post wine-devel"... User unknown
Reporting-MTA: dns; wine.codeweavers.com
Received-From-MTA: DNS; mxout.hispeed.ch
Arrival-Date: Mon, 26 Jan 2004 07:53:28 -0600



I'm trying to run the Windows xcopy (no, don't ask :)
It needs two more dlls (ulib.dll, ifsutil.dll) and then is almost happy. The only thing
left it complains about is this:

err:module:import_dll No implementation for ntdll.dll.NtSetThreadExecutionState 
imported from L"C:\\windows\\system\\ifsutil.dll", setting to 0xdeadbeef

Can anybody help me with a stub? Maybe this gets things further.

Thanks

bye  Fabi 

Wrong LANG message

[Fabian Cenedese]

Hi

When I start wine I always get a message about several possible
language ids and that I need to set LANG to the specific sub id.
But even after that I still get this message. I need to set LANGUAGE
to the sub id, then wine keeps quiet. So either my setup is quite
wrong or this message needs to be changed to set LANGUAGE.

Thanks

bye  Fabi

WineDbg didn't stop

[Fabian Cenedese]

Hi

I tried to debug a program. I set a breakpoint but winedbg didn't stop though
it said the breakpoint was set. Here's the output:

Wine-dbg>b CIncoExpCtrl::OnCreate
Unable to add breakpoint, will check again when a new DLL is loaded
Wine-dbg>c
...
(0x42a2)
Loaded debug information from 32bit DLL 'C:\WINDOWS\SYSTEM\INCOEXP.OCX' (0x1000)
Breakpoint 2 at 0x1001a910 (CIncoExpCtrl::OnCreate [C:\IncoExp\Src\IncoExpCtl.cpp:382] 
in INCOEXP.OCX)

(yep, right file and right line)

First chance exception: e06d7363 in 32-bit code (0x404b96f3).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:1007 GS:
 EIP:404b96f3 ESP:408ce044 EBP:408ce0a0 EFLAGS:0216(   - 00  I   -A-P1 )
 EAX:408ce044 EBX:40574c78 ECX: EDX:000c
 ESI:408ce0e0 EDI:408ce064
Stack dump:
0x408ce044 (KERNEL32.DLL.VerSetConditionMask+0x36e206):  e06d7363 0001  
404b9660
0x408ce054 (KERNEL32.DLL.VerSetConditionMask+0x36e216):  0003 19930520 408ce10c 
5f4bb5d8
0x408ce064 (KERNEL32.DLL.VerSetConditionMask+0x36e226):   42a5 42a5 
780012b3
0x408ce074 (KERNEL32.DLL.VerSetConditionMask+0x36e236):   408ce1fa 408ce0b8 
78001385
0x408ce084 (KERNEL32.DLL.VerSetConditionMask+0x36e246):  42a5 0002 0010 
408ce1fa
0x408ce094 (KERNEL32.DLL.VerSetConditionMask+0x36e256):   7802ee08 408ce0e0 
408ce0e0
0x408ce0a4 (KERNEL32.DLL.VerSetConditionMask+0x36e266):

0200: sel=1007 base=40018000 limit=1f83 32-bit rw-
Backtrace:
=>0 0x404b96f3 (KERNEL32.DLL.RaiseException+0x93 in KERNEL32.DLL) (ebp=408ce0a0)
  1 0x7800ac4e (MSVCRT.DLL._CxxThrowException+0x34 in MSVCRT.DLL) (ebp=408ce0e0)
  2 0x5f47d5b1 (MFC42.DLL.1269+0x4d in MFC42.DLL) (ebp=408ce104)
  3 0x5f48ceab (MFC42.DLL.2464+0x11c in MFC42.DLL) (ebp=408ce19c)
  4 0x5f423445 (MFC42.DLL.4035+0x51 in MFC42.DLL) (ebp=408ce1c4)
  5 0x5f42348d (MFC42.DLL.6095+0x43 in MFC42.DLL) (ebp=408ce1ec)
  6 0x5f423520 (MFC42.DLL.5719+0x28 in MFC42.DLL) (ebp=408ce220)
  7 0x5f42375d (MFC42.DLL.6198+0x14 in MFC42.DLL) (ebp=408ce288)
  8 0x5f421996 (MFC42.DLL.6621+0x86 in MFC42.DLL) (ebp=408ce2e0)
  9 0x5f42168b (MFC42.DLL.6623+0x3f in MFC42.DLL) (ebp=408ce31c)
  10 0x5f421647 (MFC42.DLL.2135+0x59 in MFC42.DLL) (ebp=408ce370)
  11 0x1001a9d5 (CIncoExpCtrl::OnCreate+0xc5(lpCreateStruct=0x5f401aff, cPath=0x1) 
[C:\IncoExp\Src\IncoExpCtl.cpp:401] in INCOEXP.OCX) (ebp=408ce470)
...

What? We already passed the breakpoint? Why didn't it stop? Did I
do something wrong?

Thanks

bye  Fabi

Still SSTab, OleAut32.dll

[Fabian Cenedese]

Hi

I'm still trying to get some VB programs to run on wine (actual cvs).
But I always get the error that it can't load the SSTab control from
TabCtl32.ocx as described here:

http://www.winehq.org/hypermail/wine-devel/2003/12/0157.html

I now tried setting some dlls to native and found that it works (well,
further) if I set OleAut32.dll to native, the others are still builtin.
What is missing? Has this to do with the typelib or anything else?
Testcase is simple: Create a new VB(6)-Project and place the
tab control (from TabCtl32.ocx which has to activated first) on
the empty dialog. Run the exe on wine.

Any pointers?

Thanks

bye  Fabi

Re: wine cvs notes and proposed keyboard detection fix.

[Fabian Cenedese]

>That shouldn't happen. Keyboard detection code always does a full round
>of comparisons with every keyboard table in x11drv.

Ahmm... I don't have keyboard problems, just out of curiosity: Would it speed
up wine starting if the keyboard was configured fixed and wine wouldn't have
to test all possible layouts?

bye  Fabi

Re: Mouse up vs Mouse click

[Fabian Cenedese]

At 14:15 19.12.2003 +, Mike Hearn wrote:
>On Fri, 2003-12-19 at 14:01, Fabian Cenedese wrote:
>> The control is a bit quirky with moving focus around and handling events
>> specially. But still it works on Windows :) Now I'm a bit lost how I can
>> debug this. +mouse didn't show anything usefull. I guess the
>> generating and sending of the events is done in the wineserver.
>
>+event,+message is useful, look in dlls/x11drv/event.c for the
>translation from X events to Win32 messages.

The log messages were not that helpful, I know try to have a look at
the source, but I need more knowledge.

>I think I might have a similar bug to this in AVImark. Basically the bug
>is to do with mouse events on context menus - in normal context menus
>you get RMB down, RMB up, context menu appears. In this RichEdit
>derivative, it goes: RMB down, context menu appears, user picks an
>option, context menu disappears, RMB up, context menu appears again.

Could somebody explain me (or direct me to info) how this should work
in general? I mean even on Windows, when is something a click and
when a down/up or down/click? I know that a too slow double-click will
be two separate clicks, but I'm uncertain about the down/up events.

Thanks

bye  Fabi

Re: Problem with Access-mdb/DAO

[Fabian Cenedese]

>>If you have a string like "Nodes", then the BSTR DWORD value should be
>>5*sizeof(WCHAR) == 5*2 == 10, *NOT* 5.
>>
>>In other words, we don't have an even/odd division problem, but rather a
>>problem with the string length, since it should have been twice as much.
>>
>>Please try to find out which function created that BSTR with this wrong
>>length calculation and try to fix it.
>
>Actually that's a normal WINAPI function called SysAllocStringByteLen.
>It's used in the DAO stuff from MFC. A COleVariant is created with
>explicit type VT_BSTRT. This happens in the constructor:
>
>COleVariant::COleVariant(LPCTSTR lpszSrc, VARTYPE vtSrc)
>{
>USES_CONVERSION;
>ASSERT(vtSrc == VT_BSTR || vtSrc == VT_BSTRT);
>UNUSED(vtSrc);
>
>vt = VT_BSTR;
>bstrVal = NULL;
>
>if (lpszSrc != NULL)
>{
>#ifndef _UNICODE
>if (vtSrc == VT_BSTRT)
>{
>int nLen = lstrlen(lpszSrc);
>bstrVal = ::SysAllocStringByteLen(lpszSrc, nLen);
>}
>else
>#endif
>{
>bstrVal = ::SysAllocString(T2COLE(lpszSrc));
>}
>
>if (bstrVal == NULL)
>AfxThrowMemoryException();
>}
>}
>
>So not every BSTR is really a wide char string. That's why MSDN says
>that SysStringLen has to give back the allocated length if the BSTR
>was created with SysAllocStringByteLen.
>
>I made a short test program:
>
>COleVariant v1;
>VariantInit(&v1);
>v1=COleVariant("Nodes", VT_BSTRT);
>cout << SysStringLen(v1.bstrVal) << " " << (char*)v1.bstrVal << endl;
>
>Output on Windows:
>2 Nodes
>
>Output on wine:
>2 Node
>
>(And you're right, the SysStringLen is ok, reports also 2 on Windows).
>
>The SysAllocStringByteLen is ok, but the variant assignment is done
>with VariantCopy which is definitely wrong. The source string is still
>ok but the dest string is only "Node". But this function is above my
>knowledge. I don't know if the allocation/copy is wrong or if it needs
>a new case for these special non-WCHAR BSTRs.
>
>(Another interesting test: What happens with one-char-strings...?)

Ok, I just tried and changed the code a bit. This now works with
normal wide char strings as well as binary data (may as well be an
ASCII string) with type BSTR. Though it works for me it may not
be the right solution.

bye  Fabi


Index: wine/dlls/oleaut32/variant.c
===
RCS file: /home/wine/wine/dlls/oleaut32/variant.c,v
retrieving revision 1.83
diff -u -r1.83 variant.c
--- wine/dlls/oleaut32/variant.c6 Jan 2004 22:08:34 -   1.83
+++ wine/dlls/oleaut32/variant.c8 Jan 2004 10:05:25 -
@@ -727,7 +727,7 @@
   {
 if (V_BSTR(pvargSrc))
 {
-  V_BSTR(pvargDest) = SysAllocStringLen(V_BSTR(pvargSrc), 
SysStringLen(V_BSTR(pvargSrc)));
+  V_BSTR(pvargDest) = SysAllocStringByteLen((char*)V_BSTR(pvargSrc), 
SysStringByteLen(V_BSTR(pvargSrc)));
   if (!V_BSTR(pvargDest))
 hres = E_OUTOFMEMORY;
 }

Mouse up vs Mouse click

[Fabian Cenedese]

Hi

Where is decided if I release the mouse button if a mouse up or a mouse
click is generated? Is this time dependent? Or generally the same?

The misbehaving app uses a ownerdrawn, CListCtrl-derived list. When
I click on a cell not in the first column the cell gets selected. But on
wine I can see that the selection flashes shortly and disappears right
again (Surprisingly it works when I click in the first column. As my
application uses the same code for all columns it must be something
else.). After putting some debug messages in my code I found that
on Windows after the left-button-down event a left-button-click event
is generated, no matter how long I hold the button before releasing.
On wine there is no click event but a mouse up event. And the cell
flashes even when I hold the button, so it's not the releasing itself
that clears the selection.

The control is a bit quirky with moving focus around and handling events
specially. But still it works on Windows :) Now I'm a bit lost how I can
debug this. +mouse didn't show anything usefull. I guess the
generating and sending of the events is done in the wineserver.

Thankful for any hints.

bye  Fabi

DC ownerdrawn background mode

[Fabian Cenedese]

Hi

I have a control derived from CListCtrl. It's completely ownerdrawn. The
problem comes when some item is selected. The whole column is drawn
selected but the text is drawn with the actual back color instead of
transparent. As this is white I get white text on white background... very
readable :)

I found that the difference between Windows and wine is the background
mode. In Windows it's transparent whereas in wine it's opaque. I never
change the background mode in my app, I guess I just lived from the
fact that it's default transparent. Where is this set? Is this a wrong
default parameter in wine or do I explicitly have to set the background
mode in my app? I can do this, then it shows ok. But that's another
change to my application I have to do because of wine. Maybe other
apps may have similar problems.

bye  Fabi

// from my code:

void CMyCtrl::DrawItem(LPDRAWITEMSTRUCT lpDrawItemStruct) 
{
// Prepare and test device context
CDC* pDC = CDC::FromHandle(lpDrawItemStruct->hDC);

// this is 1 for windows but 2 for wine
// pDC->GetBkMode();

// wine fix
pDC->SetBkMode(TRANSPARENT);