Hans Leidekker wrote:
Hi,
Here's the beginnings of an MSCMS.DLL (color management) on top of the LittleCMS library. I had to resort to some rather ugly preprocessor trickery to be able to include lcms.h, since it happens to define basic Windows types when not compiled on Windows ;-(.
-Hans
Changelog: Beginnings of an MSCMS implementation based on LittleCMS.
Is adding this to the Wine tree likely to break more apps than it fixes? How much work will you be doing on this library? Will we get into the same state as SHDOCVW where the DLL is essentially useless?
Rob
On Saturday 18 September 2004 19:47, Robert Shearman wrote:
Is adding this to the Wine tree likely to break more apps than it fixes?
Well, I don't have real numbers but MSCMS 2.0 is around since Windows 98, so I'd say most apps that use it expect it to be present. Those are broken on Wine now, so if we can add basic MSCMS functionality to Wine some of these may start to work.
How much work will you be doing on this library?
Hey, this is open source! It's hard to say but I will attempt to get that basic functionality done. One could argue that because it's not certain when MSCMS will be done we should add anything already done to the central repository sooner rather than later, for others to see and build upon.
Will we get into the same state as SHDOCVW where the DLL is essentially useless?
SHDOCVW needs the Mozilla based ActiveX control right? If I understand your question you're worried that because people don't have liblcms installed MSCMS will be useless. Well, I know liblcms is part of SUSE, Mandrake and Debian. It's not in Fedora Core but it is in Fedora Extras.
liblcms (LittleCMS) is only 384Kb so we could also consider statically linking it, an option pretty much out of the question for the Mozilla based control. A third option would be to build LittleCMS as another dll (it support this), implement MSCMS on top of it, and simply ship that as another Wine specific dll.
Does that answer your question?
-Hans
Hans Leidekker wrote:
On Saturday 18 September 2004 19:47, Robert Shearman wrote:
Will we get into the same state as SHDOCVW where the DLL is essentially useless?
SHDOCVW needs the Mozilla based ActiveX control right? If I understand your question you're worried that because people don't have liblcms installed MSCMS will be useless.
No. I am asking whether it will end up sitting there remaining 5% implemented (I think the 25% on the DLLs status page is a little generous) because no-one will have the time and expertise to implement the rest. Admittedly, this is different from SHDOCVW where it consists of many undocumented functions and interfaces.
Well, I know liblcms is part of SUSE, Mandrake and Debian. It's not in Fedora Core but it is in Fedora Extras.
liblcms (LittleCMS) is only 384Kb so we could also consider statically linking it, an option pretty much out of the question for the Mozilla based control. A third option would be to build LittleCMS as another dll (it support this), implement MSCMS on top of it, and simply ship that as another Wine specific dll.
It is not a problem if liblcms isn't installed as we could print a FIXME and return FALSE from PROCESS_ATTACH to get the same behaviour as before.
Rob
On Sunday 19 September 2004 14:43, Robert Shearman wrote:
No. I am asking whether it will end up sitting there remaining 5% implemented (I think the 25% on the DLLs status page is a little generous) because no-one will have the time and expertise to implement the rest. Admittedly, this is different from SHDOCVW where it consists of many undocumented functions and interfaces.
I don't think it's that bad with MSCMS. It's pretty well documented, ICC profiles are standardized and LittleCMS appears to supply at least the basic functionality that I suspect most apps are after, which is translating an image from one color space into another.
-Hans
liblcms (LittleCMS) is only 384Kb so we could also consider statically linking it, an option pretty much out of the question for the Mozilla based control.
Actually we pretty much have to "statically link" the ActiveX control as it must be built as Win32 code. In fact the easiest thing to do is simply download the prebuilt version from Adams webpage, as compiling Mozilla is sort of a pain, then drop the PE DLL into c:\windows\system.
If it weren't for Alexandres dislike of binaries in CVS I'd have asked for it to be put in there already seeing as the number of people who have it installed is roughly zero. Currently we just say "download it from the website" but unfortunately it seems most packagers are not aware of its presence and do not include it. Ditto for the other binaries Wine can use but aren't included in the source tree (stdole32.tlb, fonts, etc)
This is just a variant of the "no community developed binary packages" problem coming back to bite us ...
A third option would be to build LittleCMS as another dll (it support this), implement MSCMS on top of it, and simply ship that as another Wine specific dll.
Hmm, lesser of two evils here:
- Include LittleCMS and increase the build time but make Wine easier to install [correctly]
- Don't include it and have yet another magic dependency that isn't detected by packager build systems, and results in mysterious failures at runtime alerted only by a fixme that may be drowned out in others.
At some point somebody needs to compile a list of all the optional dependencies we use so packaging systems that support the concept of recommended/suggested packages can get this right.
thanks -mike
Mike Hearn wrote:
Actually we pretty much have to "statically link" the ActiveX control as it must be built as Win32 code. In fact the easiest thing to do is simply download the prebuilt version from Adams webpage, as compiling Mozilla is sort of a pain, then drop the PE DLL into c:\windows\system.
If it weren't for Alexandres dislike of binaries in CVS I'd have asked
I think a good solution would be to add code to wine to offer to download it and install when it is needed.
That should be only a few lines of code using MessageBox() and URLDownloadToFileW()... something like the following patch, but perhaps with a progress bar, and internationalized messages?
Mike
Index: dlls/shdocvw/shdocvw_main.c =================================================================== RCS file: /home/wine/wine/dlls/shdocvw/shdocvw_main.c,v retrieving revision 1.20 diff -u -r1.20 shdocvw_main.c --- dlls/shdocvw/shdocvw_main.c 25 Aug 2004 17:33:47 -0000 1.20 +++ dlls/shdocvw/shdocvw_main.c 20 Sep 2004 09:53:28 -0000 @@ -45,6 +45,10 @@ #define MOZILLA_ACTIVEX_MESSAGE "You need to install the Mozilla ActiveX control to\n" \ "use Wine's builtin CLSID_WebBrowser from SHDOCVW.DLL"
+#define MOZILLA_ACTIVEX_DOWNLOAD "This application is requesting an ActiveX browser object\n" \ + "but the Mozilla Active X control is currently not installed." \ + "Do you wish to download and install it?" + DEFINE_GUID( CLSID_MozillaBrowser, 0x1339B54C,0x3453,0x11D2,0x93,0xB9,0x00,0x00,0x00,0x00,0x00,0x00);
typedef HRESULT (WINAPI *fnGetClassObject)(REFCLSID rclsid, REFIID iid, LPVOID *ppv); @@ -125,6 +129,47 @@ return S_FALSE; }
+static BOOL SHDOCVW_TryDownloadMozillaControl() +{ + char *szUrl = "http://www.iol.ie/~locka/mozilla/MozillaControl16.exe"; + char *szProg = "%TEMP%\MozillaControl16.exe"; + char path[MAX_PATH]; + typeof(URLDownloadToFileA) *df; + HMODULE hUrlMon; + DWORD r; + STARTUPINFOA si; + PROCESS_INFORMATION pi; + MESSAGE(MOZILLA_ACTIVEX_DOWNLOAD "\n"); + + hUrlMon = LoadLibraryA("urlmon"); + if( !hUrlMon ) + return FALSE; + + df = (typeof(URLDownloadToFileA)*) GetProcAddress( hUrlMon, "URLDownloadToFileA" ); + if( !df ) + return FALSE; + + r = MessageBoxA(NULL, MOZILLA_ACTIVEX_DOWNLOAD, "Wine", MB_YESNO | MB_ICONQUESTION); + if( r != IDYES ) + return FALSE; + + r = ExpandEnvironmentStringsA( szProg, path, MAX_PATH ); + if( !r ) + return FALSE; + + r = df( NULL, szUrl, path, 0, NULL ); + if( r != S_OK ) + return FALSE; + + memset( &si, 0, sizeof si ); + si.cb = sizeof si; + r = CreateProcessA( path, NULL, NULL, NULL, 0, 0, NULL, NULL, &si, &pi ); + if( !r ) + return FALSE; + + WaitForSingleObject( pi.hProcess, INFINITE ); + return TRUE; +}
static BOOL SHDOCVW_TryLoadMozillaControl() { @@ -134,6 +179,9 @@ return hMozCtl ? TRUE : FALSE;
if( !SHDOCVW_GetMozctlPath( szPath, sizeof szPath ) ) + SHDOCVW_TryDownloadMozillaControl(); + + if( !SHDOCVW_GetMozctlPath( szPath, sizeof szPath ) ) { MESSAGE(MOZILLA_ACTIVEX_MESSAGE "\n"); MessageBoxA(NULL, MOZILLA_ACTIVEX_MESSAGE, "Wine", MB_OK | MB_ICONEXCLAMATION); @@ -143,7 +191,7 @@ hMozCtl = LoadLibraryExW(szPath, NULL, LOAD_WITH_ALTERED_SEARCH_PATH); if( !hMozCtl ) { - ERR("Can't load the Mozilla ActiveX control\n"); + ERR("Can't load the Mozilla ActiveX control from %s\n", debugstr_w(szPath)); return FALSE; } return TRUE;
I think a good solution would be to add code to wine to offer to download it and install when it is needed.
That should be only a few lines of code using MessageBox() and URLDownloadToFileW()... something like the following patch, but perhaps with a progress bar, and internationalized messages?
Hey yes, that's a fantastic idea! It doesn't generalize to the other cases for the Moz ActiveX control that would work wonderfully. Let's do it! :)
On Mon, 20 Sep 2004, Mike Hearn wrote: [...]
At some point somebody needs to compile a list of all the optional dependencies we use so packaging systems that support the concept of recommended/suggested packages can get this right.
Would it help if we modify the configure script to display a list of the optional dependencies that were not detected. I have attached a very rough prototype that displays a message if NAS, Alsa or ICU is not found:
$ ./configure ... many many lines later ... config.status: executing windows commands
Notes: *** NAS not detected. The winenas.drv.so driver will be a dummy. *** ICU not detected. Building without bidi support.
Configure finished. Do 'make depend && make' to compile Wine.
I only did this for 3 of the optional dependencies. This would obviously have to be generalized to the others (and the messages can probably be improved too). But this could help users and packagers detect what's missing to have a full-featured Wine build. It would certainly be simpler than having to scan the configure output: not everyone would realize that a missing xpg4 library won't impact Wine's capabilities (or at least I believe it won't), while a missing ubidi.h header means no bidirectional text support.
Would it help if we modify the configure script to display a list of the optional dependencies that were not detected. I have attached a very rough prototype that displays a message if NAS, Alsa or ICU is not found:
Yes, it would. Quite a few other projects do this and it's very helpful.
Notes: *** NAS not detected. The winenas.drv.so driver will be a dummy. *** ICU not detected. Building without bidi support.
Configure finished. Do 'make depend && make' to compile Wine.
I think there's no need for the *** notation though. We can just indent them.
The idea is very very good, but I have a couple of comments:
Francois Gouget wrote:
+echo +echo "Notes:"
Why not use the autoconf macro specific for this purpose? I think it's called "AC_WARN" or something.
echo "*** Alsa not detected. The winealsa.drv.so driver will be a dummy."
echo "*** NAS not detected. The winenas.drv.so driver will be a dummy."
I think a more user oriented description is in order here. This is too alarming, and the list will be flooded by newbies asking whether it's possible to run wine without them.
Instead, use a terminology according to the line of "Wine will not be able to produce sound using the Alsa driver".
+if test -z "$ICULIBS"
I do believe this is the wrong test. If we must do it here, test for "HAVE_ICU".
- echo "*** ICU not detected. Building without bidi support."
Again, gotta avoid Jargon. Let's face it, 99% of Wine users don't care about this one. Instead, write:
"Building wine without BiDirectional languages (Hebrew, Arabic) support"
This will greatly reduce the number of users alarmed by this configure message.
Shachar
Francois Gouget fgouget@free.fr writes:
Would it help if we modify the configure script to display a list of the optional dependencies that were not detected. I have attached a very rough prototype that displays a message if NAS, Alsa or ICU is not found:
$ ./configure ... many many lines later ... config.status: executing windows commands
Notes: *** NAS not detected. The winenas.drv.so driver will be a dummy. *** ICU not detected. Building without bidi support.
I think the default messages should be restricted to the things that most users care about, which is basically what we do already (with FreeType for instance). 99% of our users couldn't care less if NAS or ICU is missing, so we shouldn't add noise about that.
If the goal is to help packagers to get it right, then we can add a --enable-packager-mode option that does extra diagnostics without unnecessarily scaring end users.
On Mon, Sep 20, 2004 at 09:44:51AM +0100, Mike Hearn wrote:
If it weren't for Alexandres dislike of binaries in CVS I'd have asked for it to be put in there already seeing as the number of people who have it installed is roughly zero. Currently we just say "download it from the website" but unfortunately it seems most packagers are not aware of its presence and do not include it. Ditto for the other binaries Wine can use but aren't included in the source tree (stdole32.tlb, fonts, etc)
We should have a binary package on our SF site. What do we need in there? I would guess: - Mozilla Active X - fonts
What else?
We should have a binary package on our SF site.
Well, do you mean a package of drop-in files for your virtual windows drive? If so then I agree, but it'd make sense to have some support for this in wineprefixcreate, something like:
overlay_dir="@libdir@/wine/windows-drive-binary-overlay" if [ -d "$overlay_dir" ]; then cp -r "$overlay_dir" $WINEPREFIX/drive_c/ fi
And then the binary package can just be a tarball you can extract to /usr/lib/wine or somesuch (lib as it's not arch-neutral).
In theory then binary packagers would include them in their packages. In practice quite a lot of users either install Wine from the source, or use packages built by people who don't track Wine development (*cough* gentoo *cough*) so this wouldn't solve the problem for a lot of people.
Perhaps a notice at the end of the configure script in big loud letters saying "YOU SHOULD DOWNLOAD HTTP://WHATEVER/! DO IT! DO IT NOW!" would help.
Some packagers quite clearly ignore changes in Wine itself and just bump the date when there's a new release, but I don't think there's anything we can do about that except have a generic downloader program which would download the binary package as needed. That'd be very silly indeed. Probably best to just let those users lose.
What do we need in there? I would guess:
- Mozilla Active X
- fonts
A stdole32.tlb, the program Huw posted can be used to generate it (on Windows) and it only has to be done once. Of course hopefully at some point that will be moving into the build system. Until it does, we can stick it in there.
Hmmm. I think that's all we need right now.
Maybe in future if we get some documentation in WinHelp or CHM format, we could put the generated binary files there too. Obviously we don't need that currently ...
thanks -mike
Le lun 20/09/2004 à 10:53, Mike Hearn a écrit :
We should have a binary package on our SF site.
Well, do you mean a package of drop-in files for your virtual windows drive? If so then I agree, but it'd make sense to have some support for this in wineprefixcreate, something like:
overlay_dir="@libdir@/wine/windows-drive-binary-overlay" if [ -d "$overlay_dir" ]; then cp -r "$overlay_dir" $WINEPREFIX/drive_c/ fi
And then the binary package can just be a tarball you can extract to /usr/lib/wine or somesuch (lib as it's not arch-neutral).
I'd prefer a tarball extracted during wineprefixcreate, but that's only a preference.
Which files (except the Mozilla Active X) is not arch-neutral? Fonts are, stdole32.tlb (as created by the Codeweavers program) is.
In theory then binary packagers would include them in their packages. In practice quite a lot of users either install Wine from the source, or use packages built by people who don't track Wine development (*cough* gentoo *cough*) so this wouldn't solve the problem for a lot of people.
I tried to contact the author of the Gentoo Wine ebuild with a patch enhancing it, 3 times even, still no answer to this date. Any Gentoo users reading this? Anyone knows why he doesn't answer? Or wanting to do a takeover of the ebuild?
Perhaps a notice at the end of the configure script in big loud letters saying "YOU SHOULD DOWNLOAD HTTP://WHATEVER/! DO IT! DO IT NOW!" would help.
Some packagers quite clearly ignore changes in Wine itself and just bump the date when there's a new release, but I don't think there's anything we can do about that except have a generic downloader program which would download the binary package as needed. That'd be very silly indeed. Probably best to just let those users lose.
Vincent
Which files (except the Mozilla Active X) is not arch-neutral? Fonts are, stdole32.tlb (as created by the Codeweavers program) is.
You said it already, Moz AX control isn't. Might as well keep them all in one place.
A virtual Windows drive isn't useful for non-IA32 users anyway, as they can't run just any old Win32 binaries. So it's sort of a moot point ...
On Mon, Sep 20, 2004 at 03:53:27PM +0100, Mike Hearn wrote:
In theory then binary packagers would include them in their packages. In practice quite a lot of users either install Wine from the source, or use packages built by people who don't track Wine development (*cough* gentoo *cough*) so this wouldn't solve the problem for a lot of people.
A 'lot' is a bit of an exageration. It seems our binary packages are quite popular, please check the download stats (apprently they have been fixed as of late on SF :)). So getting our packagers to include them would be a great step forward. Also, providing a separate package for the folks that insist to build from source (under Support Files), would solve the problem for most of the other users.
What do we need in there? I would guess:
- Mozilla Active X
- fonts
A stdole32.tlb, the program Huw posted can be used to generate it (on Windows) and it only has to be done once. Of course hopefully at some point that will be moving into the build system. Until it does, we can stick it in there.
Cool, all of this should work just fine. Now we need to get someone to maintain this package...
A 'lot' is a bit of an exageration. It seems our binary packages are quite popular, please check the download stats (apprently they have been fixed as of late on SF :)). So getting our packagers to include them would be a great step forward. Also, providing a separate package for the folks that insist to build from source (under Support Files), would solve the problem for most of the other users.
We get ~6000 downloads a day right now which is OK but not that great, given the size of the project. There are the other following sources which are not tracked:
- People following CVS - People using the source releases - Gentoo users, Debian users, FreeBSD users, FoobarLinux users who use apt-get or equivalents and so on.
I would not be at all surprised if added up, the downloads from these sources outnumbered the SF.net downloads by a fair bit. After all, Alexandre felt that keeping ./tools/wineinstall was worth it even though it doesn't do much these days simply because so many users would ask (more) questions otherwise ...
On Mon, Sep 20, 2004 at 04:53:54PM +0100, Mike Hearn wrote:
A 'lot' is a bit of an exageration. It seems our binary packages are quite popular, please check the download stats (apprently they have been fixed as of late on SF :)). So getting our packagers to include them would be a great step forward. Also, providing a separate package for the folks that insist to build from source (under Support Files), would solve the problem for most of the other users.
We get ~6000 downloads a day right now which is OK but not that great, given the size of the project. There are the other following sources which are not tracked:
- People following CVS
- People using the source releases
- Gentoo users, Debian users, FreeBSD users, FoobarLinux users who use apt-get or equivalents and so on.
I have a ftp.suse.com/pub/people/meissner/wine dir which is in the default "apt for SUSE" path and most likely in related howtos. Neithertheless I get 5000 downloads for our current distro per month on SourceForge. ;)
Ciao, Marcus
Le lun 20/09/2004 à 11:53, Mike Hearn a écrit :
A 'lot' is a bit of an exageration. It seems our binary packages are quite popular, please check the download stats (apprently they have been fixed as of late on SF :)). So getting our packagers to include them would be a great step forward. Also, providing a separate package for the folks that insist to build from source (under Support Files), would solve the problem for most of the other users.
We get ~6000 downloads a day right now which is OK but not that great, given the size of the project.
~30000 for the last 7 days. Yes, I'm surprised to see that, for example, the French translations of Mozilla/Firefox/Thunderbird score higher downloads than Wine. Maybe switch to bi-weekly releases, as Gaim?
There are the other following sources which are not tracked:
- People following CVS
- People using the source releases
The primary mirror for the source releases is sf.
- Gentoo users, Debian users, FreeBSD users, FoobarLinux users who use apt-get or equivalents and so on.
I would not be at all surprised if added up, the downloads from these sources outnumbered the SF.net downloads by a fair bit. After all, Alexandre felt that keeping ./tools/wineinstall was worth it even though it doesn't do much these days simply because so many users would ask (more) questions otherwise ...
I think we need to better advertise major build/usage changes in Wine. The change to dosdevices still brings a lot of questions in #winehq, mostly from people modifying their config and finding nothing changes in Wine. People still want to change version on the commandline, or set desktop, or use --debugmsgs.
Once in a while, I think a change which actually breaks things is good, as it forces people to learn the proper way to do something, and not rely on second-hand knowledge from 4 years ago. Of course letting the user know how to put it back together quickly is required :)
Vincent
~30000 for the last 7 days. Yes, I'm surprised to see that, for example, the French translations of Mozilla/Firefox/Thunderbird score higher downloads than Wine. Maybe switch to bi-weekly releases, as Gaim?
I don't think it makes sense to compare ourselves to Mozilla, tempting though it is.
For one, those programs run on Windows and as such have a much larger userbase. For another, everybody these days uses a web browser and email client but many Linux users don't need Windows emulation.
No, I don't think bi-weekly releases makes sense. We may as well just tell people to use CVS. If anything we want to slow down and do more like 6 monthly releases.
The primary mirror for the source releases is sf.
Don't forget ibiblio. That's where I always get mine from, and it's what's linked to in the official announcements. But yes, OK, we send a lot of traffic to SourceForge.
I think we need to better advertise major build/usage changes in Wine. The change to dosdevices still brings a lot of questions in #winehq, mostly from people modifying their config and finding nothing changes in Wine. People still want to change version on the commandline, or set desktop, or use --debugmsgs.
I agree, our communication is not so great, but I don't know how to improve it :(
Remember that a lot of users don't read *anything*, they simply download an RPM or use apt/emerge/urpmi/... and start playing with it maybe following an ancient HOWTO. Where do we publish information of changes?
Once in a while, I think a change which actually breaks things is good, as it forces people to learn the proper way to do something, and not rely on second-hand knowledge from 4 years ago. Of course letting the user know how to put it back together quickly is required :)
The config file changes could have been managed better, if only by shoving a comment at the top automatically saying that the drives had been migrated. It's clear from the number of people who actually advise others to use winecfg (!) that many don't read what's printed on stderr.
Actually I suspect some users are getting installs which simply send the output of Wine to /dev/null. I recall seeing at least one package that did this.
How much work will you be doing on this library?
Hey, this is open source! It's hard to say but I will attempt to get that basic functionality done...
Will we get into the same state as SHDOCVW where the DLL is essentially useless?
For what it's worth I don't think we should start excluding new DLLs from the tree until they reach maturity (what is mature anyway?). If they aren't in there people probably won't hack on them.
The flip side is then we end up with a ton of stub DLLs and programs that could work in its absence now break. This is a danger whenever you add stubs, it's happened with function stubs as well.
For DLLs the solution I'd like to see is simply a default loadorder of "native, builtin" for DLLs we know aren't really complete enough for most apps. Possibly we could also tie the DLL overrides to the Windows version.
For instance, if there's a DLL that only exists in Win2K or WinXP but not Win98 then when the emulator is set to win98 mode, we could have foo.dll have an override of "native" so preventing the builtin version from being used. In Win2K/WinXP mode, they'd become "native, builtin" (or maybe builtin, native if we know the native version doesn't work).
I think most users understand the version setting and play with it first when things go wrong. So by tying the usage of new/incomplete DLLs to the Windows version we make it more likely that users will stumble upon the right settings.
thanks -mike
Mike Hearn wrote:
For what it's worth I don't think we should start excluding new DLLs from the tree until they reach maturity (what is mature anyway?). If they aren't in there people probably won't hack on them.
The flip side is then we end up with a ton of stub DLLs and programs that could work in its absence now break. This is a danger whenever you add stubs, it's happened with function stubs as well.
Also maybe these DLLs can Just be excluded from the "make Install". There should be 2 DLL templates (in Makfile) one for installable DLL and one for not-installable. The packagers should make it a rule to only include Installable DLLs.
-
Alexandre Julliard -
Boaz Harrosh -
Dimitrie O. Paun -
Francois Gouget -
Hans Leidekker -
Marcus Meissner -
Mike Hearn -
Mike McCormack -
Robert Shearman -
Shachar Shemesh -
Vincent Béron