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
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...
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...
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...
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...
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...
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.
"Jan Bares" <jan....@antek.cz.no.spam> wrote in message
news:eNh9v5t2BHA.2332@tkmsftngp03...
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...
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...
> (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.
"David Bevan" <daveb*nospam*@multico.com> wrote in message
news:epvux4z2BHA.1552@tkmsftngp05...
"Brandon Bray [MSFT]" <branbra...@microsoft.com> wrote in message
news:#8CXKwM3BHA.2488@tkmsftngp04...
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.
"Dave" <ju...@junkmail.com> wrote in message
news:uFErRHN3BHA.2856@tkmsftngp05...
>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!
"David Bevan" <daveb*nospam*@multico.com> wrote in message
news:eSpj31d2BHA.1796@tkmsftngp02...
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...
Just remove the .junk from the e-mail address.
Thanks,
Dave
"David Bevan" <daveb*nospam*@multico.com> wrote in message
news:epvux4z2BHA.1552@tkmsftngp05...
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.
"Dave" <ju...@junkmail.com> wrote in message
news:#1JPDsN3BHA.2660@tkmsftngp05...
Ted.
"Mike" <a...@b.c.de> wrote in message
news:dpuraus6o23vmfjji...@4ax.com...
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.
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...
"Brandon Bray [MSFT]" <branbra...@microsoft.com> wrote in message
news:eqE#wbO3BHA.376@tkmsftngp02...
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...
>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
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
--
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
"Michael (michka) Kaplan" <forme...@nospam.trigeminal.spamless.com> wrote
in message news:uYH#TIm4BHA.2156@tkmsftngp05...
[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
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
Visual C++ compiler and libraries team
"Pavel Sokolov" <artdes...@mail.ru> wrote in message
news:e3vZXU#5BHA.1888@tkmsftngp07...
Thank you for truth.
--