why require oleacc.dll? 
Author Message
 why require oleacc.dll?

Why, oh why, is MFC70 dependent on the oleacc.dll!  I've read all the posts
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



Sat, 18 Sep 2004 08:30:53 GMT  
 why require oleacc.dll?
Reason #1: they were lazy.  All other DLLs are delay loaded but this one
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...

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.


Quote:
> Why, oh why, is MFC70 dependent on the oleacc.dll!  I've read all the
posts
> 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



Sat, 18 Sep 2004 11:23:33 GMT  
 why require oleacc.dll?
a hint at: http://wata.org/pubs/articles/win98.htm

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.

Quote:

> Reason #1: they were lazy.  All other DLLs are delay loaded but this one
> 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...

> 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.



> > Why, oh why, is MFC70 dependent on the oleacc.dll!  I've read all the
> posts
> > 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



Sat, 18 Sep 2004 11:45:02 GMT  
 why require oleacc.dll?
I've come up with an alternative solution for you.  If you wish to remove
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.


Quote:
> Why, oh why, is MFC70 dependent on the oleacc.dll!  I've read all the
posts
> 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



Sun, 19 Sep 2004 04:07:01 GMT  
 why require oleacc.dll?
Thanks for all the input Ted.

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

Quote:

> I've come up with an alternative solution for you.  If you wish to remove
> 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.



> > Why, oh why, is MFC70 dependent on the oleacc.dll!  I've read all the
> posts
> > 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



Sun, 19 Sep 2004 07:02:10 GMT  
 why require oleacc.dll?
In this case I think it's worth it to rebuild the MFC70.DLL since you are
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.


Quote:
> Thanks for all the input Ted.

> 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


> > I've come up with an alternative solution for you.  If you wish to
remove
> > 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

- Show quoted text -

Quote:
> > 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.



> > > Why, oh why, is MFC70 dependent on the oleacc.dll!  I've read all the
> > posts
> > > 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



Sun, 19 Sep 2004 08:16:20 GMT  
 why require oleacc.dll?
Hi,

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



Sun, 19 Sep 2004 15:12:58 GMT  
 why require oleacc.dll?
Yes, that's exactly what I was saying in option (2).

Ted.


Quote:
> Hi,

> 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



Sun, 19 Sep 2004 23:48:51 GMT  
 why require oleacc.dll?
Here is the ultimate solution: very easy and requires no work whatsoever.
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.


Quote:
> Why, oh why, is MFC70 dependent on the oleacc.dll!  I've read all the
posts
> 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



Mon, 20 Sep 2004 00:30:11 GMT  
 why require oleacc.dll?
AWESOME!

This works like a charm and is definitely the ultimate solution at this
point.

Thanks for the help.

Dave

Quote:

> Here is the ultimate solution: very easy and requires no work whatsoever.
> 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.



> > Why, oh why, is MFC70 dependent on the oleacc.dll!  I've read all the
> posts
> > 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



Mon, 20 Sep 2004 02:35:49 GMT  
 why require oleacc.dll?

Quote:

> (Microsoft does not want anyone using shared version of
> MFC70.DLL or MSVCR70.DLL from system32 any more ).

Huh?


Wed, 22 Sep 2004 00:31:45 GMT  
 why require oleacc.dll?

Quote:

> > (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.



Wed, 22 Sep 2004 01:58:41 GMT  
 why require oleacc.dll?
Where did you install the oleacc.dll to? Will it automatically be picked up
in the local directory even if mfc70.dll is installed in the system
directory?


Quote:
> AWESOME!

> This works like a charm and is definitely the ultimate solution at this
> point.

> Thanks for the help.

> Dave


> > Here is the ultimate solution: very easy and requires no work
whatsoever.
> > 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.



> > > Why, oh why, is MFC70 dependent on the oleacc.dll!  I've read all the
> > posts
> > > 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



Wed, 22 Sep 2004 02:41:12 GMT  
 why require oleacc.dll?
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.



Quote:

> > > (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.



Wed, 22 Sep 2004 02:45:05 GMT  
 why require oleacc.dll?
Yes, it does pick up the DLL even if mfc70.dll is in the system folder, I
confirmed this with the de{*filter*} 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.


Quote:
> Where did you install the oleacc.dll to? Will it automatically be picked
up
> in the local directory even if mfc70.dll is installed in the system
> directory?



> > AWESOME!

> > This works like a charm and is definitely the ultimate solution at this
> > point.

> > Thanks for the help.

> > Dave




Quote:
> > > Here is the ultimate solution: very easy and requires no work
> whatsoever.
> > > 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
Quote:
> > > hwnd, DWORD dwId, REFIID riid, void **ppvObject) { return 0; }

> > > extern "C"  int    __declspec(dllexport)

CreateStdAccessibleObject(HWND
Quote:
> > > hwnd, LONG idObject, REFIID riid, void** ppvObject) {return 0; }

> > > extern "C"  LRESULT      __declspec(dllexport)

LresultFromObject(REFIID

- Show quoted text -

Quote:
> > > 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.



> > > > Why, oh why, is MFC70 dependent on the oleacc.dll!  I've read all
the
> > > posts
> > > > 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



Wed, 22 Sep 2004 02:48:39 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. OLEACC.DLL required for apps built with VC++.NET

2. OLEACC.DLL required for apps built with VC++.NET

3. oleacc.dll -Active Accessability ...why is it loaded?

4. OLEACC.DLL error on Win95 for MFC apps

5. oleacc.dll problem

6. Unwanted use of 'OLEACC.dll'

7. OLEACC.dll dependency

8. Delay Loading oleacc.dll

9. oleacc.dll not found

10. Oleacc.dll new dependancy

11. loading of oleacc.dll

12. recompiled program now DEPENDS on OLEACC.DLL

 

 
Powered by phpBB® Forum Software