September 2005 - Wine-Devel

Re: [RESEND] Fwd: wineprefix create theming directories

by Alexandre Julliard

Vijay Kiran Kamuju <infyquest(a)gmail.com> writes: > Is there any thing wrong with this patch.? That should probably be done in the shell32 registration or somewhere similar, so that we don't have to hardcode the names. -- Alexandre Julliard julliard(a)winehq.org

Sept. 16, 2005

Re: listview crash fix

by Michael Jung

Hi Dimi, On Friday 16 September 2005 14:41, Dimi Paun wrote: > Try this instead, I forgot you're not supposed to return > directly out of a __TRY block. Seems to work fine for me (I had to add an ntdll import to the Makefile to get it to link). No crashes thus far. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Sept. 16, 2005

Re: Copy the generated fonts to windows/fonts

by Alexandre Julliard

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > Do you mean that GDI should try to load fonts from the build tree > if it can't find them in windows/fonts? If yes, then why do we > create symlinks to programs and copy wine.inf to windows/inf? GDI should load the fonts from the font path; if users want to run from the build tree they have to set the font path accordingly. The symlinks we create are because apps need them, not because of Wine. If you have an app that needs a font file then it's another issue, but Wine itself should not depend on that. -- Alexandre Julliard julliard(a)winehq.org

Sept. 16, 2005

Re: Copy the generated fonts to windows/fonts

by Dmitry Timoshkov

"Alexandre Julliard" <julliard(a)winehq.org> wrote: > We really shouldn't need to do that, the fonts should be loaded from > the standard install dir. If that doesn't work for some reason it > needs to be fixed. Do you mean that GDI should try to load fonts from the build tree if it can't find them in windows/fonts? If yes, then why do we create symlinks to programs and copy wine.inf to windows/inf? -- Dmitry.

Sept. 16, 2005

Re: Copy the generated fonts to windows/fonts

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Copy the generated fonts to windows/fonts. We really shouldn't need to do that, the fonts should be loaded from the standard install dir. If that doesn't work for some reason it needs to be fixed. -- Alexandre Julliard julliard(a)winehq.org

Sept. 16, 2005

Re: Copy the generated fonts to windows/fonts

by Dmitry Timoshkov

"Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > Dmitry, why we need to copy these fonts? Can we use symlinks for it? Sure, we can. I'll wait for Alexandre's comments before I'll change anything in the patch. -- Dmitry.

Sept. 16, 2005

Re: listview crash fix

by Alexandre Julliard

Dimi Paun <dimi(a)lattica.com> writes: > OK, here it is, using exceptions instead of cluttering the > code with tests all over the place. Obviously, it is much > cleaner then other methods, but we've I know we've been > hesitant to use exceptions in Wine unless absolutely > necessary due to the cost of __TRY. IMO that's really ugly, and will cause no end of maintenance nightmares. You can't just jump out like that, you'll need to check every intermediate function to make sure it unwinds properly, frees allocated memory etc. In the end it's the same work as handling the error explicitly, but it makes the code much harder to follow. -- Alexandre Julliard julliard(a)winehq.org

Sept. 16, 2005

Re: listview crash fix

by Dimi Paun

On Fri, 2005-09-16 at 08:12 -0400, Dimi Paun wrote: > On Wed, 2005-09-14 at 15:16 +0200, Michael Jung wrote: > > > To be honest, I don't like this solution at all, I'll try > > > a different approach tonight, but in the meanwhile... > > OK, here it is, using exceptions [...] Try this instead, I forgot you're not supposed to return directly out of a __TRY block. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Sept. 16, 2005

Re: Copy the generated fonts to windows/fonts

by Vitaly Lipatov

В сообщении от 16 Сентябрь 2005 16:11 Dmitry Timoshkov написал(a): > Hello, > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Copy the generated fonts to windows/fonts. Dmitry, why we need to copy these fonts? Can we use symlinks for it? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Sept. 16, 2005

Re: Copy the generated fonts to windows/fonts

by Andreas Mohr

Hi, On Fri, Sep 16, 2005 at 09:11:04PM +0900, Dmitry Timoshkov wrote: > Hello, > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Copy the generated fonts to windows/fonts. > + rm -f "$CROOT/windows/fonts/$i" && cp "$fontsdir/$i" "$CROOT/windows/fonts/$i" || echo "Warning: failed to copy $i" Is it really a good idea to force-remove old fonts? What if a misconfiguration means that someone is using his Windows partition at that place? Maybe do mv "$CROOT/windows/fonts/$i" "$CROOT/windows/fonts/$i.old" instead? That would preserve the old version, yet due to static suffix would not create another new copy each time someone runs that script (ok, it would overwrite the original windows font at the second script run, but then I'd consider it the user's own fault for not detecting it earlier and also placing a Windows partition there). Andreas Mohr

Sept. 16, 2005

Re: [AppDB] new server supports GD2

by Jeremy Newman

Yes it is. PHP Version: 4.3.10 from phpinfo() [gd] GD Support enabled GD Version 2.0 or higher FreeType Support enabled FreeType Linkage with freetype T1Lib Support enabled GIF Read Support enabled GIF Create Support enabled JPG Support enabled PNG Support enabled WBMP Support enabled On Thu, 2005-09-15 at 20:20 -0400, Chris Morgan wrote: > I didn't notice it on wine-devel. Has Jeremy confirmed that the server is > running gd2? > > Chris > > > On Thursday 15 September 2005 5:01 am, Jonathan Ernst wrote: > > Hi Chris, > > > > Something wrong with this one ? > > > > Le mercredi 31 août 2005 à 15:16 +0200, Jonathan Ernst a écrit : > > > To be applied after Jeremy confirms that GD2 is installed. > > > To test: go to the admin and regenerate all pictures > > > > > > Changelog: > > > - use GD2 php functions to get nicer screenshots > >

Sept. 16, 2005

Re: listview crash fix

by Dimi Paun

On Wed, 2005-09-14 at 15:16 +0200, Michael Jung wrote: > > To be honest, I don't like this solution at all, I'll try > > a different approach tonight, but in the meanwhile... OK, here it is, using exceptions instead of cluttering the code with tests all over the place. Obviously, it is much cleaner then other methods, but we've I know we've been hesitant to use exceptions in Wine unless absolutely necessary due to the cost of __TRY. I've done some benchmarking and on my 3GHz CPU it takes about 0.5us for a __TRY. Or about the equivalent of only 3 calls to GetWindowLongPtrW() or IsWindow(). In other words, the cost is very low for our purpose here, and certainly smaller then any other method. In fact, we can make this even faster by relying on the access violation exception instead of doing the IsWindow() test after each notification, but I was afraid we'd cover up other bugs (but there are ways around that too). The only thing that I didn't know how to do is how to come up with a custom exception code. How does one do that? Anyway, can you please give it a try and tell me if it works OK for you? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Sept. 16, 2005

Re: OleFont: Fix IDispatch Implementation (was Re: olefont: GetIDsOfNames)

by Walt Ogburn

On Wed, 14 Sep 2005, Robert Shearman wrote: > > You're not being lazy enough. All of this stuff can be easily > implemented in one go using CreateStdDispatch, as long as you know how > to use it. Try the attached patch. > > Changelog: > Return the standard font IDispatch interface created using > CreateStdDispatch on top of a typelib instead of manually implementing > the necessary methods. > Hi Robert, I'm not sure how to proceed here. My small patch makes the GetIDsOfNames in olefont work, so that programs that want to use GetIDsOfNames to get a DISPID code and then use Invoke to set font size, bold, etc. will work. With your bigger patch, IFontDisp uses the GetIDsOfNames from typelib.c, which also works, but it also uses the Invoke from typelib.c, which doesn't know how to set the font size, etc. Therefore, programs that try to get the DISPID code with GetIDsOfNames and then set some property with Invoke are broken at a different point after your patch. The thing is, I don't see how the Invoke in typelib.c can be made to get and set the font size, font weight, etc. correctly. It shouldn't know about the internal structure of OLEFontImpl, right? So how can it know that DISPID_FONT_WEIGHT and DISPID_FONT_BOLD mean doing doing different things to the same field in the OLEFontImpl, or where to find it? If you know how to make Invoke work again after your patch, that would be great. Otherwise, I could just re-submit my patch with the error handling corrected as Alexandre said. - Walter

Sept. 16, 2005

Re: [AppDB] new server supports GD2

by Chris Morgan

I didn't notice it on wine-devel. Has Jeremy confirmed that the server is running gd2? Chris On Thursday 15 September 2005 5:01 am, Jonathan Ernst wrote: > Hi Chris, > > Something wrong with this one ? > > Le mercredi 31 août 2005 à 15:16 +0200, Jonathan Ernst a écrit : > > To be applied after Jeremy confirms that GD2 is installed. > > To test: go to the admin and regenerate all pictures > > > > Changelog: > > - use GD2 php functions to get nicer screenshots

Sept. 15, 2005

Re: winspool/tests: New Testsuite

by Detlef Riekenberg

Am Samstag, den 10.09.2005, 15:32 +0100 schrieb Huw D M Davies: > On Fri, Sep 09, 2005 at 12:50:26AM +0200, Detlef Riekenberg wrote: > > > Changelog: > > > - New Testsuite for winspool.drv: > It's almost a 3000 line patch. You should try to break this down it > separate, smaller patches. I'm working at this. -- By By ... ... Detlef

Sept. 15, 2005

Re: Is Wine SMP-safe yet?

by Michael Stefaniuc

On Thu, Sep 15, 2005 at 05:50:51AM -0700, Dan Kegel wrote: > I've seen conflicting reports about whether Wine is safe > to run on SMP systems. I'm running it since 1.5 years on a SMP system (P4, HT enabled and smp kernel). I don't remember to have run into SMP problems. Or better said in the problems i tried to debug there wasn't a SMP bug. > Have the issues described in > http://www.winehq.org/hypermail/wine-devel/2005/01/0060.html > been taken care of? Don't think so. Maybe some DLLs got fixed but not due to that email. I just pinged the reporter of the only bug with SMP in the summary, > http://bugs.winehq.org/show_bug.cgi?id=2708 > to see if he can still reproduce it. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Sept. 15, 2005

Is Wine SMP-safe yet?

by Dan Kegel

I've seen conflicting reports about whether Wine is safe to run on SMP systems. Have the issues described in http://www.winehq.org/hypermail/wine-devel/2005/01/0060.html been taken care of? I just pinged the reporter of the only bug with SMP in the summary, http://bugs.winehq.org/show_bug.cgi?id=2708 to see if he can still reproduce it. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Sept. 15, 2005

Re: wineconsole --backend-user

by Robert Lunnon

On Thursday 15 September 2005 18:16, Marcus Meissner wrote: > On Wed, Sep 14, 2005 at 06:20:35PM +1000, Robert Lunnon wrote: > > After an underwhelming response to my last query, I dug a little deeper > > and while I'm not too familiar with windows code I can't seem to figure > > out what is wrong with user.c that gives me my funny display. It would > > seem that either bitblt isn't working as advertised or the memory DC > > isn't being written properly (or it's not compatible with the display > > context). Does --backend=user work under Linux ? > > > > Anyway, before I spend a great deal of time on this, I am prompted to ask > > how important is this backend, seeing I have curses working properly. I > > could easily make the user backend default to the curses implementation > > for compatibility short term. Is there a downside to this? Is this > > something that's likely to be deprecated soon ? > > --backend=user display characters for me, but has this "random" lines > between every character too. On Linux. > > Ciao, Marcus > s Thanks, at least I know I'm not totally insane, can any other linux user confirm problems with this?

Sept. 15, 2005

Re: wineconsole and solaris

by Robert Lunnon

<snip> > > did you try to pick up another font for the console and then get back to > "Wine Courier" ? Likely, there's a discrepency between font cell size > (in registry) and what the font actually does. > > A+ I did some more work and it seems that either the memory DC isn't being written properly or the bitblt is bad, perhaps referencing the wrong address or word format for the source or destination. I no longer think it's a font problem since I tried to floodfill the display DC directly and this din't work properly either. There is a report from a linux user that wineconsole --backend=user doesn't work properly under linux either. I'm just a bit confused as to the cause since this isn't really a part of wine I'm very familiar with. SInce it's broken under linux, I'm presuming --backend=user isn't very important to the functioning of wine ? Bob

Sept. 15, 2005

Re: [AppDB] new server supports GD2

by Jonathan Ernst

Hi Chris, Something wrong with this one ? Le mercredi 31 août 2005 à 15:16 +0200, Jonathan Ernst a écrit : > To be applied after Jeremy confirms that GD2 is installed. > To test: go to the admin and regenerate all pictures > > Changelog: > - use GD2 php functions to get nicer screenshots > > > > > -- Jonathan Ernst <Jonathan(a)ErnstFamily.ch>

Sept. 15, 2005

Re: wineconsole --backend-user

by Marcus Meissner

On Wed, Sep 14, 2005 at 06:20:35PM +1000, Robert Lunnon wrote: > After an underwhelming response to my last query, I dug a little deeper and > while I'm not too familiar with windows code I can't seem to figure out what > is wrong with user.c that gives me my funny display. It would seem that > either bitblt isn't working as advertised or the memory DC isn't being > written properly (or it's not compatible with the display context). Does > --backend=user work under Linux ? > > Anyway, before I spend a great deal of time on this, I am prompted to ask how > important is this backend, seeing I have curses working properly. I could > easily make the user backend default to the curses implementation for > compatibility short term. Is there a downside to this? Is this something > that's likely to be deprecated soon ? --backend=user display characters for me, but has this "random" lines between every character too. On Linux. Ciao, Marcus

Sept. 15, 2005

Re: OleFont: Fix IDispatch Implementation (was Re: olefont: GetIDsOfNames)

by Walt Ogburn

Wait a minute, hold that - after this patch, you can't use Invoke any more to get and set the members of IFontDisp! With the current code, it works. Alexandre, please don't commit that yet. Thanks, Walter On Wed, 14 Sep 2005, Robert Shearman wrote: > Walt Ogburn wrote: > > >Changelog: > > Implement IFontDisp::GetIDsOfNames > > > > > > > > You're not being lazy enough. All of this stuff can be easily > implemented in one go using CreateStdDispatch, as long as you know how > to use it. Try the attached patch. > > Changelog: > Return the standard font IDispatch interface created using > CreateStdDispatch on top of a typelib instead of manually implementing > the necessary methods. > > -- > Rob Shearman > >

Sept. 15, 2005

Re: Internet Explorer Registry entries

by James Liggett

Hi Stefan, I agree. I personally thought this would have been done long ago. But, in order to fully implement this functinality, wouldn't we have to implement some more dll's (like shdoc401 and some others that I don't know off the top of my head?) The reason I ask this is that some programs (like Office, Visio, maybe others) seem to look for stuff like that, and currently a lot of installs refuse to work because of it. James On Wed, 2005-09-14 at 21:50 +0200, Stefan Dösinger wrote: > Hello, > I just tried to install Palm Desktop on a clean Wine installation to test the > msi file on Wine's MSI implementation. Well, it cancelled the installation > because it needs MSIE 4.0 or higher. > > My suggestion is to include the most important Internet Explorer > identification registry entries in the default wine registry to make apps > like this install without the hassle of installing Internet explorer. If the > version is set to 4.0, 5.0 or 5.5 IE6.0 SP1 should still install without > problems. > > To my knowledge most apps check for the existance of MSIE to be sure some DLLs > are available on Win95 systems, which wine brings in builtin versions. All > apps(except of Steam) that I've seen and require MSIE work fine with Wines > shdocvw, mshtml and friends. > > What do you think about this? > Stefan > >

Sept. 14, 2005

HTML Help is functional

by James Hawkins

Hey, As soon as the last hhctrl patch is committed (embedding in the correct window), HTML Help will be functional. That means that you can open up a chm help file with wine's help viewer, hh. It requires IE6 to be installed for the time being, until our shdocvw and mshtml are up to par. You'll also need a copy of native itss.dll (it has to be registered with wine): $ regsvr32 itss.dll $ WINEDLLOVERRIDES=shdocvw,mshtml,urlmon,shlwapi,itss=n wine hh helpfile.chm A few things need to be completed, but not much. Most noticeably the toolbar buttons need to be drawn and submitted to wine-patches. If you would like to help in that area, send me an email and I'll let you know how it needs to be done. The tabs are blank and need filling in. Attached is a screenshot of hh in action. If anyone has any comments or suggestions, let me know and I'll address those. Thanks, James Hawkins

Sept. 14, 2005

Re: Problem detecting libxslt

by Vincent Béron

Le mer 14/09/2005 à 06:20, Alexandre Julliard a écrit : > Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > > > Is this acceptable? > > > > libxslt/xslt.h was never included, so I got rid of it. > > > > The variable declarations weren't protected with the HAVE_LIBXSLT_*_H > > macros, so I simplified the test and removed the macros. > > I think keeping the standard header check is better. What didn't work > with your previous solution? Nothing, I simply misunderstood your comment "Looks good to me" while answering Mike's proposal of an AC_TRY_COMPILE() test, and the patch wasn't applied yet, so I jumped to some wrong conclusions :) Note that libxslt/xslt.h is still unused in Wine's code, so I don't see why we check for it. Also, even if the header inclusion is protected, variable declarations using types from those headers are not, so if one is missing you'll still get a compilation error during make. I'll resubmit the first patch with the libxslt/xslt.h check removed. Vincent

Sept. 14, 2005