how-to block ads
|
|
Share Topic
 |
 |
|
|
|
| reply to OZO
Re: Firefox 3 honors Windows Security Zones... said by OZO:No, it is not. It is not a function of OS unless of cause you think that IE is part of the OS. It's function of a browser. It's IE browser, who has separated security settings for different web sites it's visiting, and it's IE, that made up 3 so called zones (trusted web sites, common Internet sites, restricted sites). Other browsers may do different determinations regarding their security settings for different web sites. IAttachmentExecute is exposed through the file shdocvw.dll (Source: »msdn.microsoft.com/en-us/library···85).aspx )
Shdocvw.dll supplies the functionality associated with navigation, in-place linking, favorites and history management, and PICS support. This DLL also exposes interfaces to its host to allow it to be hosted separately as an ActiveX control. The Shdocvw.dll component is more frequently referred to as the WebBrowser Control. In-place linking refers to the ability to click a link in the HTML of the loaded document and to load a new HTML document in the same instance of the WebBrowser Control. If only Mshtml.dll is being hosted, a click on the link results in a new instance of the browser. (Source: »msdn.microsoft.com/en-us/library···85).aspx )
However, IAttachmentExecute is not tied, in any way, to Internet Explorer. Internet Explorer makes use of IAttachmentExecute from a file that deals with HTML and hyperlinking. IExplore.exe is at the top level; it is a small application that is instantiated when Internet Explorer is loaded. This executable application uses Internet Explorer components to perform the navigation, history maintenance, favorites maintenance, HTML parsing and rendering, and so on, while it supplies the toolbar and frame for the stand-alone browser. IExplorer.exe directly hosts the Shdocvw.dll component. (Source: »msdn.microsoft.com/en-us/library···85).aspx )
shdocvw.dll is a system shared component for anything that needs HTML or hyperlinking (which includes Outlook, the Help system). shdocvw.dll is not Internet Explorer. shdocvw.dll is one of many components that make up Internet Explorer. Saying that shdocvw.dll (component) is the same as Internet Explorer (application) is like saying Hydrogen (H, atom) is the same as Water (H2O, molecule). Thus, I say that IAttachmentExecute is a feature provided by the operating system in a resource that is currently used by the supplied web browser, email system, etc.
said by OZO:Prompt is issued by a program manager (Windows Explorer) and not by OS. Try to execute :Zone.Identifier marked file in e.g. CMD window. And, BTW, you can easily replace WE by a different program manages (and OS is still running, of cause)... That is because it is the responsibility of the launcher (Windows Explorer) to make use of IAttachmentExecute. Old code or code that ignores this feature do not explicitly make use of the Prompt method. (Source: »msdn.microsoft.com/en-us/library···85).aspx )
Microsoft probably didn't want every single executable to be put through IAttachmentExecute (which would be stupid, costly, and slow), so instead of putting in deep into the OS (kernel?), it's a higher level API that should be called before the OS runs the downloaded file.
--
less talk, more music | |
OZOPremium
join:2003-01-17
kudos:2 | said by Ctrl Alt Del:shdocvw.dll is a system shared component for anything that needs HTML or hyperlinking (which includes Outlook, the Help system). shdocvw.dll is not Internet Explorer. shdocvw.dll is one of many components that make up Internet Explorer. Saying that shdocvw.dll (component) is the same as Internet Explorer (application) is like saying Hydrogen (H, atom) is the same as Water (H2O, molecule). Thus, I say that IAttachmentExecute is a feature provided by the operating system in a resource that is currently used by the supplied web browser, email system, etc. You've made a lot of efforts explaining what shdocvw.dll is and why it's not IE, but, at the same time, why it's an important component for an HTML browser.
Let me ask you a question - why FF doesn't use that important component then?
Isn't that because the security model of IE (based on mentioned component) is flaky (as many of users see it, I'm not one of them, BTW) and over-convoluted (as I see it) to the level that the user needs something different? If the reason to develop a new browser is not an offering of a new security model, then why do that at all? If the answer is "yes, it's not what we need", then why there is an urge to repeat the same security model in the FF.3?
Some browsers (e.g. Maxthon or MyIE) do benefit from that component (shdocvw.dll). Many web site developers will then say a big thanks for not developing and testing their sites for two different rendering engines used by IE and FF. I know they certainly will appreciate *that* simplification (there are other drawbacks though)... So, why we need yet another browser (FF.3) that is based on the same security model of IE, but offering a different rendering engine (a headache for web developers and users, who suffer from various formattings of web pages in different brothers)?
P.S. Sorry, but this post looks more like a rant from my side leading away from the subject of the thread, so you may want not to answer the questions above...
--
Keep it simple, it'll become complex by itself... | |
| said by OZO:You've made a lot of efforts explaining what shdocvw.dll is and why it's not IE, but, at the same time, why it's an important component for an HTML browser. Let me ask you a question - why FF doesn't use that important component then? Because Firefox uses its own HTML rendering engine: Gecko. Firefox is an entire web browser with no dependencies on external components. If Firefox used shdocvw.exe, then it could become another browser that is basically a new shell on top of the core from IE (Maxthon, MyIE).
This Wikipedia article does a good job at describing the IE architecture: »en.wikipedia.org/wiki/Internet_E···itecture
Files hosted by the Internet Explorer main executable, iexplore.exe:
- WinInet.dll: handles HTTP and FTP.
- URlMon.dll: handles MIME-type stuff.
- MSHTML.dll: contains the Trident rendering engine which is responsible for displaying the pages on-screen and handling the Document Object Model of the web pages.
- ShDocVw.dll: provides the navigation, local caching and history functionalities.
- BrowseUI.dll: responsible for the browser user interface, including the browser chrome, which houses all the menus and toolbars.
ShDocVw.dll also apparently contains the API for the Attachment Manager. I guess it made the most sense to stick a feature that deals with downloaded files in a DLL that is used by IE.
said by OZO:Some browsers (e.g. Maxthon or MyIE) do benefit from that component ( shdocvw.dll). Many web site developers will then say a big thanks for not developing and testing their sites for two different rendering engines used by IE and FF. I know they certainly will appreciate *that* simplification (there are other drawbacks though)... So, why we need yet another browser (FF.3) that is based on the same security model of IE, but offering a different rendering engine (a headache for web developers and users, who suffer from various formattings of web pages in different brothers)? Because it's good to have choice? Yes, Firefox is a different web browser with its own rendering engine. But, that's why we have web standards. Some web browsers aren't as good as others, but aside from nuances, both give you a webpage with the important stuff in the right place.
--
less talk, more music | |
|
