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."
Well we just celebrated the Get Firefox day. Perhaps the day IE7 gets pushed via Windows update would be yet another Get Firefox day.
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.
Could they push a copy of Halo 2 and Crimson skies via Windows Update while they're at it?
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.
This would be a problem if users could not select which updates to install and which to ignore. DuranDuran, for instance, has been without the Microsoft Malicious Software tool since it was first released.
He has also been referring to himself in the third person since earlier this morning.
"You can justify anything by putting it in quotes, adding a famous name and making it a sig" - Albert Einstein
"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"
I for one welcome this. IE6 sucks. Badly.
IE7 has a few problems, but the faster IE6 dies, the better.
This and as a web developer, I hope the bugs associated with pushing this app out will create a bad user experience and force developers that rely on hacks and nonstandard practices to get screwed over. I've had several sites I use not work with IE7 and the simplest has been because their simple javascript that detects IE versions tells me I need to use IE5.5 or greater. I've had others not work with the activeX controls because of new security models (or so I imagine).
The sooner developers move towards standards the better. IE7 is a good push towards this goal, and having it pushed out buggy and forcing developers to address the idiotic IE Only Features is just another milestone on this route.
Get your quick 'n easy version of IE7 straight from the main website: www.ie7.com
Maybe I'm missing something, but I'm not sure I understand the doom and gloom of the post? It is an update afterall. And a lot of what I've read online has been positive towards 7 over 6. On top of that, the article pushes that you don't have to install it if you don't want to.
As for the ecommerce sites being broken, it's not like they haven't had time to check to make sure their sites work in the new version. When the first beta came out, even I checked to see if there were any problems with my sites. I didn't fix them straight away, but I made sure to note down where the issues were for later repair.
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.
Oh dear, somebody who doesn't understand how the internets work. Here, this is a good start. http://www.w3.org/
"I've got more toys than Teruhisa Kitahara."
to get the new update, simply remove this:
msi http://microsoft.com/xp ie6 main
and replace it with this:
msi http://microsoft.com/xp ie7 main
in your c:/etc/apt/sources.list file. then do:
apt-get update
apt-get upgrade
More like someone who is realistic and knows that all browsers have their quirks I would say personally. Not all quirks are created equal. IE is so far behind the modern browsers in implementing standards like CSS that they're no longer even in the ballpark. With the newer browsers rev'ing so much faster than IE, I don't think they'll even be in the same league for long.
The argument here isn't idealistic or puritanical or religious - it's practical. CSS allows web developers to effectively separate content and presentation, which in turn allows for more efficient development. It's not about laziness either. We web developers have finite time. We either spend that time working on new features/content/layouts/whatever, or chasing down 4 year old bugs in IE.
Take as an example a group of mechanical engineers plotting designs for a car. Group A favors one brand of mechanical pencils. Group B favors another. An astute engineer might attempt to settle the matter as you do: "all mechanical pencils have their quirks." Unfortunately, group C is using crayons that are worn nearly to the nub. IE is a crayon that is worn quite to the nub.
To write off the pitiful state of IE's HTML, CSS and javascript support as "quirks" is to let MS off the hook. They leveraged their monopoly and "won" the browser wars. Having done so, it appears that they intend to use their dominant browser in order to defend their Big Two products by retarding the progress of web technologies indefinitely.
As a side note, why does "realist" now refer to people who give up on ethics (and other such long term concerns) for short-run gains?
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.
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
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