wine-devel May 2009

wine-devel@winehq.org

128 participants
234 discussions

Re: RFC on Base Wine Config
by chris ahrendt 03 May '09

03 May '09

Juan Lang wrote: >> ok then I am very confused then... >> I deleted the / mapping all together and then ran the dotest script and >> the make test scripts >> dotest fails if the / mapping is not there along with the inetmib1 >> test. I opened a bug >> concerning the inetmib test failing and was told that my configuration >> with the / mapping deleted >> was an invalid wine configuration that the / is absolutely needed by wine. >> >> So I am confused... is it required or not? >> > > It is not required. What _is_ required is that the path to the > current executable is mapped, somewhere. I suggested you remap Z: to > / as it's the default, and it was the most concise way to ensure that > your configuration met the requirement. As Ben said, you could map > any drive. Heck, you could have mapped Q: to the dlls/inetmib1/tests > directory and the inetmib1 test would have worked, while having no > mapping would not work. > --Juan > > > I realise this juan... I guess I am not being completely clear somewhat.... If I am in windows and go into explorer... go to a network drive. I do not nescisarily have to map that drive in order to run an application (so long as the DLLS it needs, if any, are not just on that drive). I can click the application and it runs. I realise this may be a fundamental difference between unix and windows but still they should theoretically run the same. Also from a command line I can do (I think if I am remembering correctly (been doing to much z work lately) ) //server/directory/app.exe and it will retrieve and run the app... (I think) Chris

5 6

Re: RFC on Base Wine Config
by chris ahrendt 03 May '09

03 May '09

Ben Klein wrote: > 2009/5/3 chris ahrendt <celticht32(a)yahoo.com>: > >> I have noticed something with reporting bugs and problems that are >> encountered... >> >> If the user is allowed to delete the Z: share to / once this is done >> things start acting strange or not working. >> > > In general, you can't run apps outside of what's linked to in > dosdevices. You certainly can't launch them from inside Wine. The link > to / is mostly there for convenience so you don't have to keep dumping > downloads (e.g. patches or small installers) in ~/.wine/drive_c every > time you want to install them, and partly to allow Wine to launch > applications in /usr/bin et al (e.g. winebrowser). > > >> Many people have done this for various reasons. >> > > Yes, and it's valid to do so. > > >> My suggestion is to do the following: >> >> 1. If we have a base configuration that should not change for settings >> IE the Z: mapping then do not allow this to be changed or deleted in >> winecfg. If someone is dumb enough to go into the ini file and delete it >> then they should know better. >> > > This would make a lot of people unhappy (like the creation of the > Universe) for "various reasons". > > >> 2. If it is critical that the Z: or drive mapping be there for / then >> if its missing should wine then handle this condition? >> > > 1) It's not critical. > 2) Wine already handles this condition. It's no different from any > other drive link in this way. It doesn't even have to be Z; you can > manually change it to be D if you really want. The only critical drive > is C: and that IS handled differently (especially in winecfg). > > > ok then I am very confused then... I deleted the / mapping all together and then ran the dotest script and the make test scripts dotest fails if the / mapping is not there along with the inetmib1 test. I opened a bug concerning the inetmib test failing and was told that my configuration with the / mapping deleted was an invalid wine configuration that the / is absolutely needed by wine. So I am confused... is it required or not? and if it is then we get back to my original RFC here =D Chris

2 1

RFC on Base Wine Config
by chris ahrendt 03 May '09

03 May '09

I have noticed something with reporting bugs and problems that are encountered... If the user is allowed to delete the Z: share to / once this is done things start acting strange or not working. Many people have done this for various reasons. My suggestion is to do the following: 1. If we have a base configuration that should not change for settings IE the Z: mapping then do not allow this to be changed or deleted in winecfg. If someone is dumb enough to go into the ini file and delete it then they should know better. 2. If it is critical that the Z: or drive mapping be there for / then if its missing should wine then handle this condition? Chris

2 1

error report
by Ruben Hillewaere 03 May '09

03 May '09

Hello, I wanted to install (Dar)wine on my Intel Mac, first I've tried with the binaries found on http://wiki.winehq.org/MacOSX/Installing The installation goes fine, but running any of the apps fails. So, instead, I've tried to build Wine from Scratch, this is what I get: ruben@CakeSlicer:~/distrib$ ./create_darwine_distrib.sh $VERSION ~/ Desktop/wine-$VERSION # Packaging Darwine for version 1.1.20 using Wine sources in /Users/ ruben/Desktop/wine-1.1.20... # Building Wine in /Users/ruben/Desktop/wine-1.1.20 (warning: takes a long time)... configure: WARNING: mach-o/dyld_images.h: present but cannot be compiled configure: WARNING: mach-o/dyld_images.h: check for missing prerequisite headers? configure: WARNING: mach-o/dyld_images.h: see the Autoconf documentation configure: WARNING: mach-o/dyld_images.h: section "Present But Cannot Be Compiled" configure: WARNING: mach-o/dyld_images.h: proceeding with the preprocessor's result configure: WARNING: mach-o/dyld_images.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## configure: error: FreeType development files not found. Fonts will not be built. Use the --without-freetype option if you really want this. ***** Error: Can't build wine thanks for keeping me informed about this error, Ruben Hillewaere PhD student, COMO Vrije Universiteit Brussel Department of Computer Science Pleinlaan 2 B-1050 Brussels Belgium

2 1

Re: IE and MSN Messenger 7.0
by Ben Klein 03 May '09

03 May '09

2009/5/1 Cissyvonwinckelmann <cissyvonwinckelmann(a)planet.nl>: > hartelijk dank Benm ja ik moet snel een andere pc hebben, want dit is een > hele ouwe dan krijg je de moeilijkheden, > groetjes cissy > I have to use Google Language Tools to translate your text, so I apologise if I misunderstand you. The "old problems" with Messenger (you actually didn't say which Messenger it is, Yahoo or MSN?) in Wine are not likely to go away without a lot of work. As this is the developers' mailing list, we would welcome patches/modifications to Wine to make it work better. Without a discussion on the development side, your questions are better directed to wine-users mailing list or the forum, or some other user-oriented support path. Regardless, it is strongly recommended that you look into using a native client (i.e. something you don't need Wine to run) such as Pidgin.

2 2

RE: Question about my user32 tests patch
by Ge van Geldorp 02 May '09

02 May '09

Hi Joel, > From: Joel Holdsworth <joel(a)airwebreathe.org.uk> > > How do you deal with this problem, because presumably not every test > contributor has VMs ready to confirm the behaviour of 95, 98, ME, 2000, > XP and Vista. Do I submit the patch as-is, in the knowlege that it will > cause failures in old windows? Presumably not - so what do you suggest I > do? I have a whole bunch of VMs set up specifically for Wine testing, so feel free to send me patches you think might behave differently on different Windows versions. One caveat: I personally stopped caring about 9x when Win2000 came out, so I'm not testing on those versions. The good (but unsurprising) news is that your new tests pass on all my XP (4 different configurations) and Win2k3 (also 4 different configurations) machines. I don't see failures on NT4, but perhaps the test was skipped there? The bad news is they failed on W2k, Vista and Win2k8. I've attached the test reports for all failures. Ge.

1 0

Re: Implement gdiplus.dll.GdipSetPathGradientPresetBlend
by Vincent Povirk 02 May '09

02 May '09

> +GpStatus WINGDIPAPI GdipSetPathGradientPresetBlend(GpPathGradient *brush, GDIPCONST REAL *blend, > + GDIPCONST REAL *pos, INT count) The types here don't match MSDN: http://msdn.microsoft.com/en-us/library/ms534047(VS.85).aspx

1 0

FYI: First running winelib64-port!!!
by André Hentschel 02 May '09

02 May '09

Hi, afer playing around with about 20 source-codes of open-source-project it got one compiled as winelib64-app(and also as 32-Bit winelib-app). It is WinVi 2.99 (http://www.winvi.de). The only difference i found between the original build and my two winelib builds are some GUI-specific things. Tomorrow i will have a look where to write something down about that in the wiki. As i already wrote, PuTTY compiles as winelib64-app, too, but it doesn't run. That's the reason why i called WinVi the first winelib64-app. Best regards André Hentschel

1 0

Question about my user32 tests patch
by Joel Holdsworth 02 May '09

02 May '09

Hi All, I just submitted my first ever patch to wine-patches (attached) - good news. In retrospect I may have been a little premature. The patch adds tests for user32:DrawIcon and user32:DrawIconEx including tests for icon alpha blending which wine does not currently support. It occured to me that my alpha tests will fail in versions of Windows that don't support alpha blending - but the problem is I'm not sure at what point alpha began to be supported. I only have a VM for XP - and I think, but I don't know for sure, that alpha icons began to be supported in 2000. How do you deal with this problem, because presumably not every test contributor has VMs ready to confirm the behaviour of 95, 98, ME, 2000, XP and Vista. Do I submit the patch as-is, in the knowlege that it will cause failures in old windows? Presumably not - so what do you suggest I do? I now have code to make DrawIcon pass the alpha tests, and I'm hoping to have DrawIconEx ready in a few hours. With these done it should be possible to in-cooperate my Tango patches, which should improve the appearance of wine quite substantially. Thanks Joel

2 2

FYI: 64-Bit Winelib-compilation
by André Hentschel 02 May '09

02 May '09

Hi, these days i got my gcc 4.4 working and first compiled wine64. Next thing i did was to modify winemaker to generate Makefiles for 64-Bit compilation. I first tried something simple and it worked great, so i took my modified Putty-sourcecode and gave it a try. And wow it worked great! Just compiled fine. To my suprise it didnt run. Since todays git, the modified winemaker got in and i hope it might be usefull! Best regards André Hentschel

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel May 2009