Re: MSCMS: new dll
~3 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.
Re: MSCMS: new dll
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
Re: MSCMS: new dll
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
Re: MSCMS: new dll
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 - 1.20
+++ dlls/shdocvw/shdocvw_main.c 20 Sep 2004 09:53:28 -
@@ -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;
Re: MSCMS: new dll
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.
--
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
Cahn's Axiom: When all else fails, read the instructions.Index: configure.ac
===
RCS file: /var/cvs/wine/configure.ac,v
retrieving revision 1.309
diff -u -r1.309 configure.ac
--- configure.ac16 Sep 2004 20:34:27 - 1.309
+++ configure.ac20 Sep 2004 10:34:43 -
@@ -1756,6 +1756,8 @@
AC_OUTPUT
+echo
+echo Notes:
if test $have_x = no
then
echo
@@ -1781,6 +1783,21 @@
echo *** enable Wine to use TrueType fonts.
fi
+if test -z $ALSALIBS
+then
+ echo *** Alsa not detected. The winealsa.drv.so driver will be a dummy.
+fi
+
+if test -z $NASLIBS
+then
+ echo *** NAS not detected. The winenas.drv.so driver will be a dummy.
+fi
+
+if test -z $ICULIBS
+then
+ echo *** ICU not detected. Building without bidi support.
+fi
+
echo
echo Configure finished. Do '${ac_make} depend ${ac_make}' to compile Wine.
echo
Re: MSCMS: new dll
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.
Re: MSCMS: new dll
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? -- Dimi.
Re: MSCMS: new dll
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
Re: MSCMS: new dll
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 -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: MSCMS: new dll
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... -- Dimi.
Re: MSCMS: new dll
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 ...
Re: MSCMS: new dll
Francois Gouget [EMAIL PROTECTED] 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. -- Alexandre Julliard [EMAIL PROTECTED]
Re: MSCMS: new dll
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 pgpgvwp59nRze.pgp Description: PGP signature
Re: MSCMS: new dll
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. ~3 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
Re: MSCMS: new dll
On Sunday 19 September 2004 06:06, Dmitry Timoshkov wrote: 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 ;-(. Then perhaps it's better to make lcms.h think that it's used in a Windows environment (define WIN32 or whatever it wants to see before inclusion). That will help to completely avoid all the ugliness with redefined stuff. Yes, I tried that option but it has even bigger problems. First, the header doesn't have such a define! It defaults to building on non-windows platforms and requires you to edit the file if you want a Windows build. Furthermore, when you do so it immediately includes windows.h, which is not allowed within Wine. You have to use FIXMEs not TRACEs above to clearly indicate the status of the APIs. Yes, thanks for pointing that out. I'll send an updated patch. -Hans
Re: MSCMS: new dll
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
Re: MSCMS: new dll
On Sun, Sep 19, 2004 at 09:29:39AM +0200, Hans Leidekker wrote: On Sunday 19 September 2004 06:06, Dmitry Timoshkov wrote: Yes, I tried that option but it has even bigger problems. First, the header doesn't have such a define! It defaults to building on non-windows platforms and requires you to edit the file if you want a Windows build. Furthermore, when you do so it immediately includes windows.h, which is not allowed within Wine. It's probably best to also try to submit a patch to the Little CMS folks so we can have a better solution in the future. -- Dimi.
Re: MSCMS: new dll
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
Re: MSCMS: new dll
On Sunday 19 September 2004 17:31, Dimitrie O. Paun wrote: It's probably best to also try to submit a patch to the Little CMS folks so we can have a better solution in the future. Sure, will do. -Hans
Re: MSCMS: new dll
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
Re: MSCMS: new dll
Hans Leidekker [EMAIL PROTECTED] wrote:
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 ;-(.
Then perhaps it's better to make lcms.h think that it's used in a Windows
environment (define WIN32 or whatever it wants to see before inclusion).
That will help to completely avoid all the ugliness with redefined stuff.
+HPROFILE WINAPI OpenColorProfileA( PPROFILE profile, DWORD access, DWORD sharing,
DWORD creation )
+{
+TRACE(stub ( %p, %lx, %lx, %lx )\n, profile, access, sharing, creation );
+
+return NULL;
+}
+
+HPROFILE WINAPI OpenColorProfileW( PPROFILE profile, DWORD access, DWORD sharing,
DWORD creation )
+{
+TRACE(stub ( %p, %lx, %lx, %lx )\n, profile, access, sharing, creation );
+
+return NULL;
+}
+
+BOOL WINAPI CloseColorProfile( HPROFILE profile )
+{
+TRACE(stub ( %p )\n, profile );
+
+return FALSE;
+}
You have to use FIXMEs not TRACEs above to clearly indicate the status
of the APIs.
--
Dmitry.
