Slashdot Mirror
IE7 to be Pushed to Users Via Windows Update
dfrick writes "CNET is reporting that IE7 will be pushed to users via Windows Update. This has serious implications for e-commerce websites whose functionality might be affected by any bugs in the software. Also to have end users suddenly using a new browser right before the holiday shopping season could magnify the cost any bugs that might create a bad user experience on sites."
My favorite quote FTA: "It will be available from Microsoft's Download Center Web site, Schare said. "We're really trying to get the world ready for a major new browser release."
Sorry, I already got my "major new browser release" about the time Microsoft were claiming "nobody needs tabbed browsing." IE7 is too little, too late, even for the poor unfortunates I know who are still stuck running Windows.
I've fiddled around with beta 3 for a bit, it's just as stable as IE6 is (even moreso, if you can believe that). I think this summary was written by someone scared of "beta" software.
As for breaking webpages, big deal. IE6 has been breaking webpages for years. Now at least the web designers who built pages for the IE6 "standard" instead of the STANDARD standards will taste a bit of our pain.
Only IE7 bug I noticed is that IE7 REFUSES to remove borders on iframes (or maybe it's the body tag inside the iframe). Using CSS or deprecated HTML attributes have no effect. IE6 does not have this problem.
Ironic that I received that message as I was reading this story, and about to post that automatic update will only download IE7, but will give the users a choice of whether or not to install it. Kind of like the message I just received for Firefox.
Bandwidth is really the only issue with this release method, but not so much for a single user. Businesses who would be affected by the download can install the IE7 Update Blocker Toolkit to prevent even the download.
This really isn't that big of a deal.
about:config
browser.sessionhistory.max_total_viewers set to 0
Problem solved.
Windows could have 'another' application that could call the IE DLLs, sure, but they are NO MORE PRELOADED than FIREFOX. As they would BE IN A DIFFERENT process that IE DOES NOT HAVE ACCESS TO.
.. but that's a whole different can of worms.
IE has to re-load all of its DLL even if another application has already loaded the Windows HTML rendering engine. So the memory reported in TaskMgr for IE is WHAT IE IS USING. Get it?
Um... what did the above just mean? If I remember my CS courses correctly, the reason DLL's exist is to REUSE the CODE by putting it ONCE in MEMORY and then allowing ACCESS from (gasp) DIFFERENT applications. Perhaps you are talking about DATA. There, you will have separate pages copied. That does no mean that CODE does not take space. If I am correct in assuming the HTML rendering engine code IS provided as a DLL, and the IE is just a wrapper around it, the rendering CODE could easily take 5-10MB of RAM, because rendering engines ARE COMPLEX.
Moreover, in Windows, fonts are bundled into the DLLs, making them shared as well. This means that IE can re-use fonts loaded into the HTML rendering engine, while Firefox probably cannot (It would make no point to write a browser that depends on another rendering engine, IMHO).
That's what I think the parent meant.
If you need substantiation for these claims, here you go (wikipedia):
The shared library term is slightly ambiguous, because it covers at least two different concepts. First, it is the sharing of code located on disk by unrelated programs. The second concept is the sharing of code in memory, when programs execute the same physical page of RAM, mapped into different address spaces. It would seem that the latter would be preferable, and indeed it has a number of advantages. For instance on the OpenStep system, applications were often only a few hundred kilobytes in size and loaded almost instantly; the vast majority of their code was located in libraries that had already been loaded for other purposes by the operating system.
In Windows, the concept was taken one step further, with even system resources such as fonts being bundled in the DLL file format. The same is true under OpenStep, where the universal "bundle" format is used for almost all system resources.
And, BTW, you're wrong about denied access. There is a function in the Windows API that allows any process run a thread in another process. Yep, any app can do that. From the Phrack magazine, issue 62:
The CreateRemoteThread function creates a thread that
runs in the address space of another process.
HANDLE CreateRemoteThread(
HANDLE hProcess,
LPSECURITY_ATTRIBUTES lpThreadAttributes,
DWORD dwStackSize,
LPTHREAD_START_ROUTINE lpStartAddress,
LPVOID lpParameter,
DWORD dwCreationFlags,
LPDWORD lpThreadId
);
Two more functions:
VirtualAllocEx()
WriteProcessMemory()
give us the power to inject our own arbitrary code to the
address space of another process - and once it is there, we can
create a thread remotely to execute it.
Simply because it's permanently browser dependent and proprietary, and thus has no place on any website whose purpose isn't related to pushing updates into windows installations.
Well the good news is, they fixed most CSS2.1 bugs in IE7. They killed almost every bug mentioned at positioniseverything.net. They also added support for CSS2 selectors.
The bad news is they didn't add ":after" support..
If you used this to clear floats without structural markup, you need to find another way.
And worth mentioning:
Note that pages render fine now without this hack!
The best way to accelerate a windows server is by 9.81 m/s2
You must be new here. Here are a few reasons, some of them obvious:
Only to idiots, are orders laws.
-- Henning von Tresckow
The reason is simply that AX is the only technology where a webpage can directly affect your system. Yes, that is convenient and the opportunities are incredible. But so is the danger.
The internet is, by its very nature, to be considered an insecure and hostile network. Pages you surf to are by definition to be seen as hostile until proven benign. And even then, it's happened more than once that a page considered safe was hacked and turned into a malicious site.
AX is a "direct link" between net applications and your system. Which is incredibly convenient, but also incredibly dangerous considering the described problems with the internet. If the internet was a trusted medium, this would be THE technology. Since it is not, it is THE threat.
Yes, PEBKAC is part of this danger. But then, think again how many of the "killer viruses" that spread within the last few years relied ONLY on the stupidity of people and how successful they were. ILoveYou, Kournicova (or however she's spelled) and their variants required user interaction to become active. Without a stupid user, these programs would have had zero chance of spreading.
A web application or technology has no business with my machine's system. It may run in a sandbox, which is great, it may read/write in certain, predetermined places (which are secured against the rest of the system), that's it. Giving an application from an insecure, potentially malicious, source the ability to run at system level is simply and plainly stupid. It's like playing russian roulette with 5 chambers loaded and, after hearing the 'click' once, thinking that nothing can happen and it's safe.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
You know, this is the best troll I've heard in a while. And it's scored "+5 informative". Wow.
1) DLLs are shared across processes. If one process loads a DLL, it resides in physical memory, at a specific virtual address. If another process loads the same DLL, it reuses the same copy in physical memory, but in a different virtual address space. It may even be loaded at a different virtual address in the second process. The pages are read-only so any attempt by either process to modify them will result in an access violation.
2) Windows explorer is a process which exists as an application called explorer.exe. It is started when you log on to Windows, and explorer.exe links to mshtml.dll and shdocvw.dll. These are the IE core DLLs (the Microsoft HTML parser and the Shell Document View, respectively). It also happens to link to gdiplus.dll, gdi.dll, user.exe, ntdll.dll and a bunch of others.
3) Internet explorer is a very small application (a few hundred KB compiled) which links into shdocvw.dll and mshtml.dll. It also happens to link to a bunch of other DLLs like ntdll.dll.
4) Firefox is another application. It links to such Windows DLLs as ntdll.dll and user.exe. It also happens to link to gecko.dll, which no other Windows application will load. Therefore when Firefox starts up, it is going to be the first to load gecko.dll.
5) Going back to point 1; every time any application loads a specific DLL, the loader will check to see if it is already present in physical memory, and will create a new virtual mapping for it. The physical memory used is shared across each process. When Windows starts, it loads the IE core DLLs. Most of IE is in memory by the time you can view the desktop. Firefox however, has a much smaller percentage of the application in memory before you click on it.
Hence: Most of IE is loaded before you click on the IE icon. Most of Firefox is not loaded until you click on the IE icon.
You are very misinformed.
I quote from the Internet Explorer developers' weblog:
No version of Internet Explorer supports XHTML. If you label XHTML as text/html, Internet Explorer will render it because it thinks it's HTML. There's a problem that XML prologs cause because of this, so they implemented a special-case workaround.
All of this is very well known to web developers, I suggest you actually ask your developers about this if you don't believe me.
XHTML is being treated as a buzzword these days. The document included in that video included a <meta> element that claimed the media type was text/html. This is not XHTML being parsed as XHTML. It's XHTML pretending to be HTML and being parsed as HTML - which is the only way in which any version of Internet Explorer can understand XHTML as it doesn't support XHTML.
In every way in which XHTML differs from HTML, Internet Explorer follows the HTML rules. If you disagree, please give examples. If you don't disagree, please explain how that means that Internet Explorer supports XHTML rather than "pretend XHTML".
Are you seriously making assumptions about what Internet Explorer supports by trying to spot implications from marketing material for a tangentially related product by the same company?
I'm sorry, but this simply isn't the case. Have you looked at the Acid2 test at all? The problems Internet Explorer has with it are either parsing problems or outright lack of support for various features of CSS and HTML. Internet Explorer's support for non-standard CSS extensions are not a factor.
You can argue that people should upgrade all you like, it makes no difference as to whether they actually do it or not. I'm saying that lots of people don't upgrade for years. Telling me that they should is completely irrelevant. It's not up to me whether they upgrade.
Bogtha Bogtha Bogtha