Last Comment Bug 710125 - Reduce LoadLibray/GetProcAddress for user32.dll and oleacc.dll on a11y
: Reduce LoadLibray/GetProcAddress for user32.dll and oleacc.dll on a11y
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: All Windows Vista
: -- normal (vote)
: mozilla13
Assigned To: Makoto Kato [:m_kato]
:
Mentors:
Depends on: 723797
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-12 21:41 PST by Makoto Kato [:m_kato]
Modified: 2012-02-03 11:42 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
fix (12.14 KB, patch)
2011-12-12 22:13 PST, Makoto Kato [:m_kato]
surkov.alexander: review+
roc: review+
Details | Diff | Review

Description Makoto Kato [:m_kato] 2011-12-12 21:41:00 PST
Current Gecko supports under Windows 2000 and later  (After switching to VS2010, it is Windows XP or later).  So we don't need to use LoadLibrary for oleacc and user32 on accessibility code.

ex. LresultFromCode is from Win2000 by http://msdn.microsoft.com/en-us/library/windows/desktop/dd318557%28v=vs.85%29.aspx.
Comment 1 Makoto Kato [:m_kato] 2011-12-12 22:13:23 PST
Created attachment 581187 [details] [diff] [review]
fix
Comment 2 Trevor Saunders (:tbsaunde) 2011-12-12 23:58:50 PST
Comment on attachment 581187 [details] [diff] [review]
fix

This means that we  will unconditionally link against oleacc.dll right?  Dows that have performance or other effects we should consider?
Comment 3 Trevor Saunders (:tbsaunde) 2011-12-13 00:05:12 PST
(asking roc for review since this touches widget/)
Comment 4 Makoto Kato [:m_kato] 2011-12-13 00:26:11 PST
(In reply to Trevor Saunders (:tbsaunde) from comment #2)
> Comment on attachment 581187 [details] [diff] [review]
> fix
> 
> This means that we  will unconditionally link against oleacc.dll right? 
> Dows that have performance or other effects we should consider?

oleacc.dll is already loaded on nspr4 and xul.dll's startup due to dependencies of shell32, comctl32 and others.
Comment 5 alexander :surkov 2012-01-22 04:32:10 PST
Comment on attachment 581187 [details] [diff] [review]
fix

Review of attachment 581187 [details] [diff] [review]:
-----------------------------------------------------------------

sorry for being slow, r=me

::: accessible/src/msaa/nsAccessibleWrap.h
@@ -333,5 @@
>  
> -  // NT4 does not have the oleacc that defines these methods. So we define copies here that automatically
> -  // load the library only if needed.
> -  static STDMETHODIMP AccessibleObjectFromWindow(HWND hwnd,DWORD dwObjectID,REFIID riid,void **ppvObject);
> -  static STDMETHODIMP NotifyWinEvent(DWORD event,HWND hwnd,LONG idObjectType,LONG idObject);

Shouldn't you use '::' prefix for methods like these? That's what we usually do for windows API calls.
Comment 6 alexander :surkov 2012-02-02 02:01:41 PST
try server build - http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/surkov.alexander@gmail.com-2d6066684fcf

Marco, can you make sure everything is ok?
Comment 7 Marco Zehe (:MarcoZ) 2012-02-02 04:22:12 PST
All good, virtual buffers are created just as normal with this try-server build.
Comment 8 alexander :surkov 2012-02-02 04:27:43 PST
inbound land https://hg.mozilla.org/integration/mozilla-inbound/rev/fb8fb19f6161
Comment 9 Masatoshi Kimura [:emk] 2012-02-02 18:39:31 PST
(In reply to Makoto Kato from comment #4)
> oleacc.dll is already loaded on nspr4 and xul.dll's startup due to
> dependencies of shell32, comctl32 and others.
Incorrect. oleacc.dll is delay loaded from system DLLs. I didn't see oleacc.dll in the address space of firefox.exe (using Process Explorer).
Comment 10 Ed Morley [:emorley] 2012-02-03 11:42:42 PST
https://hg.mozilla.org/mozilla-central/rev/fb8fb19f6161

Note You need to log in before you can comment on or make changes to this bug.