why require oleacc.dll?
David Bevan
about statically linking and delayloading or installing the msaardk.exe
redistributable on Win95 machines to get around this, but what was the
reason for this change in MFC70 in the first place? It has caused us quite
a headache. I understand MS not wanting to support an OS that is 5 - 7
years old, but we're getting stung by Win98 users too! I'm not sure why,
but a fair number of our customers apparently did not have the Active
Accessibility Options installed on their Win98 machines (I haven't heard yet
if these have been first or second edition or both). Our phones have been
ringing off the hook all day.
Obviously statically linking to the MFC library and delayloading the
oleacc.dll would have avoided this, but that wasn't an option for our
products. We have a suite of applications that use MFC including about 150
extension DLLs. I don't think our customers with dial-up internet access
would appreciate the size increase of our updates if everything was
statically linked (not to mention the fact that because of the use of
extension DLLs, we can't statically link anyway). Dynamic linking has
worked great for us with MFC 6 and we have been very happy with it.
How many MFC programmers use the Active Accessibility DLL anyway?
Very frustrating.
Dave
Ted
isn't - go figure.
Reason #2: an indirect way of forcing non-support for Windows 95 (probably a
Microsoft directive, just like .NET framework and Office XP)
All Windows 98 machines (first edition) and greater have Active
Accessibility - how did it happen - something else removed it? Source:
http://support.microsoft.com/servicedesks/fileversion/moreinfo.asp?Id=7314
Maybe there's a way to uninstall it in Add/Remove Windows Components. If
this is the case then MFC 7 is useless with a captial U. Microsoft - in 7.1
please fix this.
Ted.
"David Bevan" <daveb*nospam*@multico.com> wrote in message
news:eSpj31d2BHA.1796@tkmsftngp02...
Ted
It states that accessibility option(s) can be installed/uninstalled - This
is devastating. Imagine shipping an app that all of a sudden stops working
because someone mucks around with Add/Remove windows components.
Confirmation of this fact:
http://www.tiny.com/support/documents.asp?status=display&tdid=TDSAP0043
read the paragraph that states:
"If you have Win98 and un-installs Accessibility Options from Add/Remove
Programs then it will break our navigation. It un-installs a file used by
the MS-Active Accessibility which we use for "window watching" called
OLEACC.DLL. We need this file for Active Programs navigation. Re-install
Accessibility Options."
Looks like they were bitten by the oleacc.dll monster too.
Conclusion: if you are shipping a MFC 7 app that is dynamically linked you
MUST ship Active Accessibility redist, even on Windows 98. This sucks ass.
(sorry for the language). KB article needed immediately!
Ted.
"Ted" <t...@t--x.org> wrote in message news:uYdm4Vf2BHA.1660@tkmsftngp02...
Ted
the dependency on oleacc.dll and still continue to use the dynamic MFC 7
DLL, then you need to rebuild the MFC DLL. It is a lot easier than you
think it is. There is a makefile in the C:\program files\microsoft visual
studio .net\vc7\atlmfc\src folder called ATLMFC.MAK. It will rebuild
everything. Notice that the MFCDLL.MAK makefile in C:\program
files\microsoft visual studio .net\vc7\atlmfc\src\mfc already has oleacc.dll
delayloaded in one place (for 64 bit versions of MFC), but not the other
place. Sorry for calling Microsoft lazy - instead they were just
careless. So, edit the MFCDLL.MAK file to add the /delayload:oleacc.dll
line immediately following line 314.
Then run the following command from a Visual Studio .NET command prompt
while in the C:\program files\microsoft visual studio .net\vc7\atlmfc\src
folder :
nmake /f atlmfc.mak MFC LIBNAME=MYMFC70
Then copy the .LIB files from your C:\program files\microsoft visual studio
.net\vc7\atlmfc\lib\INTEL folder back to the original names and put them in
C:\program files\microsoft visual studio .net\vc7\atlmfc\lib, e.g.
copy MYMFC70.LIB MFC70.LIB
copy MYMFC70D.LIB MFC70D.LIB
etc.
This way your MFC apps and DLLs will always link to MYMFC70.DLL instead of
MFC70.DLL.
Now you will always have oleacc.dll delayloaded, and not called unless you
actually use EnableActiveAccessibility.
Ted.
"David Bevan" <daveb*nospam*@multico.com> wrote in message
news:eSpj31d2BHA.1796@tkmsftngp02...
David Bevan
This is really a troubling issue and wish that someone at Microsoft would
comment on it! For the most part it seems that they monitor the group
pretty well and tend commented on issues where appropriate. My assumption
is that not much has been said about this officially because it mainly
impacts Win95 users which are no longer being supported. The fact that if
someone uninstalls or chooses not to install Active Accessibility on Win98
will cause ALL dynamically linked MFC apps to fail is really unacceptable.
It's bad enough that we have to make sure our users are continually
upgrading their version of IE.
I hope that you are right that this was just a careless oversight on the
part of MS. If that's the case then maybe it will be fixed in the next
service pack (which will be SOON I hope). If it was intended to be a way to
weed out Win95 users, then it was misguided and is causing problems on a
supported OS.
While it sounds like rebuilding the MFC DLL will solve our problem, I think
I will avoid that unless it becomes absolutely necessary. It sounds like a
slippery slope into potential DLL Hell issues. Plus I would rather MS fix
and test their own bugs. If we opened the door to allowing developers to
modify MFC in house, who knows what monsters would crawl through. We also
wouldn't be able to use off-the-shelf merge modules for MFC.
One of the links you posted mentioned that Win98 does not default to install
Active Accessibility. By the sheer number of calls we received from Win98
users who had the oleacc.dll error, I wouldn't be surprised if this was
true. I wonder if that was the case for the first edition only? I haven't
taken the time yet to test this on a clean install, but I think I will as
soon as I have some time.
Dave
"Ted" <T...@t--x.org> wrote in message news:OPE3#Go2BHA.2544@tkmsftngp07...
Ted
installing it to your program folder anyway (Microsoft does not want anyone
using shared version of MFC70.DLL or MSVCR70.DLL from system32 any more ).
The merge module issue, well, it's minor enough an issue for me to not worry
about. If you did it in SourceSafe as an admin, making sure everyone gets
the proper rebuilt LIBS and DLLS, and not allow your developers to build it,
then I think you can control it fairly well. That's what I plan on doing
for the near future.
Problems with shipping OLEACC.DLL and installing it to 98:
a) Even after you do this they might go to add/remove windows components and
then remove it. So after all the effort you put into installing it, they
remove it, thereby breaking your app.
b) DLL Hell issues? OLEACC.DLL 2.0 and 1.3 differences? Who knows?
Language/localization issues? There are different versions for each country
I think.
What is the alternative:
1) Install oleacc.dll/oleaccrc.dll in your program folder on 98 ? No,
because it's a COM object so other apps will die. Also language issues may
still exist.
2) Create a dummy oleacc.dll with your own source code and implement the 3
entry points called from MFC70.DLL: AccessibleObjectFromWindow,
CreateStdAccessibleObject, and LresultFromObject, copy it to your program
folder and hope for the best. Since they're not called anyway, it should
work.
I'm gonna try to test out #2 above when I get a chance, it just might be the
"magic wand" solution for people who do not want to rebuild MFC70.DLL.
Ted.
"David Bevan" <daveb*nospam*@multico.com> wrote in message
news:uQyN9op2BHA.1856@tkmsftngp05...
Jan Bares
if you install MFC to your own directory, it is easier to create faked
OLEACC.DLL in that directory. MFC uses just three functions from that DLL.
Regards, Jan
Ted
Ted.
"Jan Bares" <jan....@antek.cz.no.spam> wrote in message
news:eNh9v5t2BHA.2332@tkmsftngp03...
Ted
This assumes that no components in your app rely on Active Accessibility
functionality. You can ensure this in MFC by not calling
EnableActiveAccessibility.
Create a Win32 DLL (Simple DLL) called OLEACC in Visual C++, then place the
following 3 function definitions in the generated oleacc.cpp:
extern "C" int __declspec(dllexport) AccessibleObjectFromWindow(HWND
hwnd, DWORD dwId, REFIID riid, void **ppvObject) { return 0; }
extern "C" int __declspec(dllexport) CreateStdAccessibleObject(HWND
hwnd, LONG idObject, REFIID riid, void** ppvObject) {return 0; }
extern "C" LRESULT __declspec(dllexport) LresultFromObject(REFIID
riid, WPARAM wParam, LPUNKNOWN punk) { return 0; }
Also, #include "unknwn.h" at the top of the file. Build the Release DLL
then copy it to your program folder. You're done.
With this DLL you are protected by any dangerous assumptions about
OLEACC.DLL already being installed on the computer. Your application can no
longer be broken by someone uninstalling that Windows component from the
system folder.
Ted.
"David Bevan" <daveb*nospam*@multico.com> wrote in message
news:eSpj31d2BHA.1796@tkmsftngp02...
David Bevan
This works like a charm and is definitely the ultimate solution at this
point.
Thanks for the help.
Dave
"Ted" <T...@t--x.org> wrote in message news:#cFMlyy2BHA.1552@tkmsftngp05...
Jeff Kohn
"Ted" <t...@t--x.org> wrote in message news:eRWP7Rq2BHA.2484@tkmsftngp07...
> (Microsoft does not want anyone using shared version of
> MFC70.DLL or MSVCR70.DLL from system32 any more ).
Huh?
Brandon Bray [MSFT]
>
> > (Microsoft does not want anyone using shared version of
> > MFC70.DLL or MSVCR70.DLL from system32 any more ).
>
> Huh?
Basically, we don't want these files to fall under system file protection.
If that were to happen, these DLLs are either "known DLLs" or transitively
so. If this were to happen, only the operating system could service these
files and doing so would be incredibly difficult for app compatibility.
It's just better that every application use its own version of these DLLs by
storing them with the rest of the files in the application directory. That
way the application is guaranteed to remain working even if the CRT or MFC
is serviced in other applications.
--
Cheerio!
Brandon Bray Program Manager in the Visual C++ Compiler Team
And now a word from the lawyers: This posting is provided "AS IS" with no
warranties, and confers no rights. You assume all risk for your use. © 2002
Microsoft Corporation. All rights reserved.
Dave
in the local directory even if mfc70.dll is installed in the system
directory?
"David Bevan" <daveb*nospam*@multico.com> wrote in message
news:epvux4z2BHA.1552@tkmsftngp05...
Dave
can't you guys fix that? The delayload suggestion is good I think.
"Brandon Bray [MSFT]" <branbra...@microsoft.com> wrote in message
news:#8CXKwM3BHA.2488@tkmsftngp04...
Ted
confirmed this with the debugger and looking at the actively loaded modules
list.
By the way, it's better if you install mfc70.dll and msvcr70.dll in your
program folder too, to avoid being a victim of DLL Hell.
Ted.
"Dave" <ju...@junkmail.com> wrote in message
news:#eqTHFN3BHA.376@tkmsftngp02...
Ted
time. Probably not until the 7.1 version of Visual C++ .NET comes out.
That's not even in beta yet as far as I know. For now you have to use one
of those workarounds to avoid oleacc problems. In summary, 1) static link
your app and delayload, or, 2) rebuild MFC70.DLL with delayload, or, 3)
create a dummy DLL named oleacc.dll with the right exports.
Ted.
"Dave" <ju...@junkmail.com> wrote in message
news:uFErRHN3BHA.2856@tkmsftngp05...
Mike
>Jeff Kohn wrote:
>>
>> > (Microsoft does not want anyone using shared version of
>> > MFC70.DLL or MSVCR70.DLL from system32 any more ).
>>
>> Huh?
>
>Basically, we don't want these files to fall under system file protection.
>If that were to happen, these DLLs are either "known DLLs" or transitively
>so. If this were to happen, only the operating system could service these
>files and doing so would be incredibly difficult for app compatibility.
>It's just better that every application use its own version of these DLLs by
>storing them with the rest of the files in the application directory. That
>way the application is guaranteed to remain working even if the CRT or MFC
>is serviced in other applications.
Basically, what you (and Microsoft?) is saying is that if the
application is just one .exe, you're better off to link with the
static (non-DLL) MFC7 library, the DLL will just give you headaches.
Since you also mention CRT here, I can only conclude one shouldn't use
the shared CRT either. Just to be safe, let's all link statically with
everything. Let's ditch USER32 and KERNEL32 also. Hell, why even
bother with an OS, let link everything into our apps! They are after
all just published API's. No wonder people loose faith.
This is also a "way out" of "dll hell", I suppose
/Mike - I didn't request 45MB executables!
Dave
to delay load or because it is in the mfc70.dll as implicit it will get
loaded regardless?
"David Bevan" <daveb*nospam*@multico.com> wrote in message
news:eSpj31d2BHA.1796@tkmsftngp02...
Dave
mfc70.dll. I might consider the dummy oleacc.dll but to use that do I need
to install the mfc70.dll to my local directory?
Also I have another message in the group regarding old versions of
msvcrt.dll microsoft has said the .dll is no longer redistributeable
but many apps are likely to still use it for old components and standard
operating procedure has been in the past to install the new Visual studio
and pick up the mfcXX.dll file and msvcrt.dll now people will find if they
do that it will crash Windows 98 users:
----------------------------------------------------------------------------
-----------
Dave" <ju...@junkmail.com> wrote in message
news:eLCbrlK3BHA.568@tkmsftngp07...> I double checked msvcrt.dll "was" a
redistributeable component and still
> will be for people using older apps like me.. but the older file needs to
be
> used. I think microsoft should have kept the version of this .dll
backward
> compatible since this was the case in the past and vendors will still be
> distributing with their app for sometime. Yes it will work if you only
> include the older msvcrt.dll in your setup and do version checking so it
> won't overwrite the new one in XP. I think you'll find other people
trying
> to do the same thing. Upgrade to VS.NET copy their standard set of files
> they redistribute so they have the latest version like we always used to
do,
> only to find out that it will blow up Win 95/98 if the new version of
> msvcrt.dll gets installed.
>
> Here is a statement from an MSDN article:
> "If you dynamically link your application to the MFC library, you will, at
a
> minimum, need to redistribute MFCx0[U].DLL and MSVCRT.DLL, where x is the
> version number."
>
> It is at
>
link:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore
> 98/HTML/_core_mfc.2f.other_dll_files.asp
>
> It does say the article is outdated for VS.NET, but this has been standard
> operating procedure for so many years you can bet a lot of people are
going
> to do this and blow up Win 95/98 machines. I suggest something be done
> about this quickly before you guys get a lot of calls from Win 95/98
users.
> (Right now few have moved to VS.NET but as they upgrade their apps you
could
> see this problem since a lot of people have old components that still use
> the older libraries and they will just redistribute their standard updated
> set as they usually did.)
>
> Thanks,
> Dave
>
"Ted" <T...@t--x.org> wrote in message news:uin4oNN3BHA.2680@tkmsftngp04...
Dave
ftc12...@hotmail.com.
Just remove the .junk from the e-mail address.
Thanks,
Dave
"David Bevan" <daveb*nospam*@multico.com> wrote in message
news:epvux4z2BHA.1552@tkmsftngp05...
Ted
system folder.
2) MSVCRT.DLL is no longer used in MFC70.DLL apps. A new file, called
MSVCR70.DLL is used instead.
I highly recommend installing MFC70.DLL and MSVCRT.DLL to your program
folder. There is no benefit at all to installing to the system folder
unless you are installing ActiveX controls to the system folder which use
MFC70 and/or MSVCR70.
It is not true that msvcrt.dll is no longer redistributable. It is true
that the XP version of msvcrt.dll, oleaut, and other system files are NOT
redistributable on older platforms.
Ted.
"Dave" <ju...@junkmail.com> wrote in message
news:#u$EC3N3BHA.2592@tkmsftngp04...
Ted
Ted.
"Dave" <ju...@junkmail.com> wrote in message
news:#1JPDsN3BHA.2660@tkmsftngp05...
Ted
to your program folder. It has nothing to do with using DLL or static
versions of MFC and the CRT when building. MFC 7 and the 7.0 CRT are no
longer considered system files, they shouldn't be used as such. They're
only put in the system folder when installing Visual Studio for convenience
when developing applications (so you don't have to keep copying to your
build folder(s)). When shipping real apps, they should go into your program
folder.
Ted.
"Mike" <a...@b.c.de> wrote in message
news:dpuraus6o23vmfjji...@4ax.com...
Brandon Bray [MSFT]
> We know that but why is MFC70.dll requiring the existance of oleacc.dll
> can't you guys fix that? The delayload suggestion is good I think.
Hi Dave,
I'm not an MFC person, but I went a spoke with a few of them. The fact
that oleacc.dll is not delay loaded is a bug in our build. It was a
mistake. I'll see if we have a KB article addressing this, and if not get
one created. I can promise that we'll at least consider it for the next
service pack.
David Bevan
Thank you! That is what I was hoping to hear when I started this thread.
Dave Bevan
"Brandon Bray [MSFT]" <branbra...@microsoft.com> wrote in message
news:eqE#wbO3BHA.376@tkmsftngp02...
Dave
"Brandon Bray [MSFT]" <branbra...@microsoft.com> wrote in message
news:eqE#wbO3BHA.376@tkmsftngp02...
Thomas Olsson
MFC70.DLL et al. Is this mentioned anywhere in the documentation or on the
MSN web site?
A question:
We use a lot of ActiveX Controls in our applications. Since these are shared
by many of our applications, we put them in "Program Files\Common
Files\Vinga System". Lets call this folder "common".
Several of these controls use MFC. Consider I have a control x.ocx in
"common". Then I have an application in another folder, "program", that also
uses MFC. I guess I should then put a copy of MFC70.DLL in both the folders
"common" and "program". Fine.
My question is, what copy of MFC70.DLL will x.ocx load when it is used by
the application?
Will the application load program\MFC70.DLL and the x.ocx load
common\MFC70.DLL?
Or will they both use program\MFC70.DLL?
/Thomas
--
Thomas Olsson, Vinga System AB, Sweden
http://www.vinga.se
(Reply adress is invalid to avoid spam)
"Ted" <T...@t--x.org> wrote in message news:etgo2KO3BHA.2048@tkmsftngp05...
Mike
>He's not saying that at all.
[referring to the following I wrote]
>> Basically, what you (and Microsoft?) is saying is that if the
>> application is just one .exe, you're better off to link with the
>> static (non-DLL) MFC7 library, the DLL will just give you headaches.
> He's saying that you should install these DLLs
>to your program folder.
If the program is only one executable, this goes against the reason to
use DLL's. It uses more space than needed (both the overhead of having
code in a DLL, and that it contains code that's possibly not used, and
it goes for both VM and disk), and the startup time of the program
becomes slower.
/Mike
Brandon Bray [MSFT]
>
> If the program is only one executable, this goes against the reason to
> use DLL's. It uses more space than needed (both the overhead of having
> code in a DLL, and that it contains code that's possibly not used, and
> it goes for both VM and disk), and the startup time of the program
> becomes slower.
Hi Mike,
What you say is true; however, the situation doesn't change much for using
msvcrt.dll or any other non-system DLL. It is good practice to distribute
any non-system file that your application needs. If your application needs
the CRT, then it should distribute it (either statically linked or as a
DLL). Relying on the CRT to be there in the system folder is bad practice.
I think the 45MB executable is a far fetch. Just combining msvcp70.dll
and msvcr70.dll gives you 795KB. Statically linking would certainly give
you much less than that, unless by some miracle of engineering you actually
used every last bit of the
Analyzing the situation, forcing you ship msvcr70.dll and possibly
msvcp70.dll in the application directory means you need to store an extra
795KB... hell, my MP3 collection out does that by many orders of magnitude.
If disk space is a concern these days, it's not because of this. Five to
ten years ago, things would have been different. And VM consumption doesn't
change -- you're using one different DLL, not two of them.
In short, yes there was a decision to trade a modicum of disk space for
application reliability. Both in the long run and right now, this is the
right design decision and the best thing for you.
As for other system DLLs, if you really don't want to rely on them --
welcome to the embedded computing market! :-)
--
Cheerio!
Brandon Bray Visual C++ Compiler and CRT Program Manager
Kurt B
this dummy dll. This is completely insane and unacceptable did they not test
on anything but XP and 2000? This deserves an immediate fix.
Kurt
Michael (michka) Kaplan
support installed? :-)
--
MichKa
Michael Kaplan
Trigeminal Software, Inc. -- http://www.trigeminal.com/
International VB? -- http://www.i18nWithVB.com/
C++? MSLU -- http://msdn.microsoft.com/msdnmag/issues/01/10/
"Kurt B" <kba...@larimore.net> wrote in message
news:uBhYRDm4BHA.2592@tkmsftngp04...
Kurt B
no where to be found. And I believe the machine has SP5.
Kurt
"Michael (michka) Kaplan" <forme...@nospam.trigeminal.spamless.com> wrote
in message news:uYH#TIm4BHA.2156@tkmsftngp05...
Jimbo
wrote:
[MFC 7 Won't run on NT4]
>I checked in the Windows Nt Setup and it is installed but this oleacc.dll is
>no where to be found. And I believe the machine has SP5.
>
>Kurt
It comes with SP6 and it's in my nt sys-folder. Wether the MFC7 app
will work is another matter as I can't test that yet.
Jim M
--
@ Derbyshire
Pavel Sokolov
> I'm not an MFC person, but I went a spoke with a few of them. The fact
> that oleacc.dll is not delay loaded is a bug in our build. It was a
> mistake. I'll see if we have a KB article addressing this, and if not get
> one created. I can promise that we'll at least consider it for the next
> service pack.
When service pack for vs.net will be released ? ( month - two - tree ? )
Pavel Sokolov,
CEZEO software,
LanTalk Network,
http://www.cezeo.com
http://www.lantalk.net
Ronald Laeremans [MSFT]
in the timeframe you indicate.
Ronald Laeremans
Visual C++ compiler and libraries team
"Pavel Sokolov" <artdes...@mail.ru> wrote in message
news:e3vZXU#5BHA.1888@tkmsftngp07...
Pavel Sokolov
be
> in the timeframe you indicate.
Thank you for truth.
--