Now, please go learn about the 1990s technique of "filesystem caching". This means that the DLLs can effectively bepreloaded even if they are loaded by another process in another memory space. All that's needed is a memory copy from the cache and a relocation, which is much cheaper than a load from disk
Wow, while I'm learning this, maybe you can explain your awesome theory how this would in ANY way reduce the memory footprint of an application. Also go on to explain how because a file 'may or may not be cached' that the application would run faster and use less RAM.
Oh wait, that is another reality. Geesh...
PS, just so the other nerds won't tease you, it is NOT a 1990s concept, caching technology has been used for a LONG time before the 1990s.
From what I heard, Windows pre-loads the HTML rendering engine. IE is just a wrapper.
If Explorer loads the HTML COM objects they could in theory be in the File Cache. That is the END of the advantage or pre-loading. See www.microsoft.com
IE specifically runs in an isolated process, again see www.microsoft.com. (In Win98 it did not and ran shared.) In Win2k, it used the process and DLL isloation and WInXP even further extended this will full COM DLL isolation, meaning it ONLY has access to its only process and vise versa.
What this means is that IE when clicking the E icon, loads the ENTIRE HTML COM DLLS and Rendering Engine 'separately' into the IE process. Just like FireFox loads it HTML Rendering core when it is launched. They are fundamentally EXACTLY the same in this regard.
Wrong again. Memory is NOT duplicated for CODE and CONSTANT DATA. That would include fonts, too. What Taskmgr is reporting is the IE wrapper, plus internal page representation (DOM) of each open web page.
Yes and No. In the context of FireFox 'reporting' more memory as the post I was responding to, the reported memory in use is the same for IE and FireFox. IE has no advantage over any other application running on the Win32 platform. Both IE and FireFox take advantage of the platform and stuff like Window's core abilities to render fonts, Bitmaps and draw to the screen.
So while you are partially correct that there could be 'system' level shared APIs in use or a shared font, FireFox would HAVE THE SAME EXACT advantage that IE does in this regard.
Why? The IE HTML Rendering Engine is not a CORE OS API, it is a separate COM DLL set of technologies that are 'included and used by Windows' but not a core API or WIN32 OS component.
Understand?
This makes no sense. Please go study computer science and come back later.
Nice... And yet I have to give 101 level lessons just to get my point across to people that apparently only read the rumors or base their Windows Knowledge on Win98 concepts.
I don't have to explain myself, go look this stuff up if you really want to know. I truly am not responsible for anyone here getting it, but I would like to hope that I make a few people think and find these answers on their own instead of accepting old ideas or new myths.
(Sad note, after all my explaining that IE has no memory footprint advantage, I pull open Taskmgr to see that IE is consuming 56mb and Firefox is consuming only 32mb. So please explain the myth once again how IE has a memory advantage over Firefox? - Sadly, everyone's argument here makes FireFox look like a bloated piece of software, it isn't.)
#1) DLLs can be shared, but the IE HTML COM objects are NOT shared, IE launches them in its own process. This shift was a security change in WinME and Win2k, that was even further extended in WinXP. IE 'could' in theory piggy back some of the HTML DLLs if another application like the shell had them loaded, but it 'specifically' DOES NOT for security reasons. (Go look this up, please. Do a google or a search on microsoft.com about COM isolation, also do a search on DLL isloation, and do a search on IE's Engine isloation from the OS.)
#2) Your assertions about DLL sharing and submitting that FireFox cannot use the Font sharing abilities of Windows are crazy. If ANY application is running under Windows and is writing to the screen in some matter, they are 'inherently' using the Win32 GDI+ API and 'shared' DLLs that all applications have access to, although there is distinction between shared core libraries and ones that are not.
#3) Your example of pushing code into another process is not needed, this is something that is well known by most people, and is not isolated to just Windows. It is something that Vista deals with in a way that shattering cannot allow process elevation. (Go look this stuff up.) Also this has NOTHING to do with whether Firefox or IE have a smaller memory footprint.
FireFox 'being a Win32' Application has JUST as much advantage to using the shared core OS DLLS as any windows application from Notepad to iTunes to Photoshop. I realize that some of the UI elements and programming in FireFox forgoes using some of the Windows APIs, but that is the FireFox teams decision and why cross platform applications often end up appearing slow and bloated and often uncompatibile with new OS releases because they do not adhere to the common UI structures or APIs provided.
This is true of FireFox running on KDE, OSX, or Win32. FireFox does employ 'some' optimizations on 'each' platform using the core OS, so FireFox is not Win32 free in any respect. For example it draws to the display context, it is using the standard Windows GDI APIs and DLLs as well.
The silliness in the responses I have seen are people are trying to define Firefox as sometihng it is and something it isn't, just as they are IE. Applications that run on ANY OS take advantage of the 'platform' available to it, the core or underlying APIs or Libraries that makeup the UI portion of the OS. (Yes we are sticking with GUI concepts here)
So Firefox can use any Windows TrueType Font, because it uses the WIndows Font API and therefore the Windows Font Rendering technologies. That is why you get cleartype in Firefox when running it on Windows, because it is LETTING Windows draw the fonts to its display bitmap, which is also something it is using Windows to maintain.
See, this is why I find your comment on the 'Fonts' as an example of something Firefox 'might not' have access to to be insane. Prove yourself wrong, next time you are at a Windows Machine, option the Option and change the Default rendering Font in FireFox to ANY Windows supported Font, and bingo, it will use that font, because it is LETTING Windows do the Font Rendering. Also notice that if cleartype is enabled, it is used and the Windows Font Hinting technology is also used.
FireFox is NOT at a loss of advantages when it comes to comparing itself to IE. If FireFox does eat more Memory (and sometimes it truly doesn't) then this is a problem with FireFox, not BECAUSE IE gets ANY special treatment in Windows.
Well it would be nice to go 'aha you are right' but sadly, it does not work this way. Sure there are caching and optimizations, but these are NOT shared DLLs in the context you are trying to paint them.
Copy on write optimizations have little bering on a separate isolated COM DLL rendering engine in Windows.
To use your example, we would have to assert that Firefox's Memory Footprint is less because it is 'also' pre-loaded and a part of Windows because it 'uses' the GDI+ of Windows for displaying Fonts and Bitmaps from the core OS APIs.
And that is quite a stretch.
I'm sure there are some low level CPU and caching operation that might help IE, but that is ONLY if a previous process has loaded the HTML rendering Engine.
And again, I will stress we are talking about the 'load times' and Memory footprint. The Memory reported by IE in the taskmgr is an accurate reflection of ALL the memory IE is using, including ALL the core HTML rendering DLLs.
So in this respect the memory footprint of IE is not reported any different than Firefox, nor does it have anything truly pre-loaded beyond the 'file caching' system, that by the time a system with low RAM gets to someone opening IE, has probably already paged out, and that is 'if' a previous applicatino has called IE rendering DLLs.
Quit trying to find 'excuses' for the crazy statement that the Windows Footprint is part of the IE footprint or that IE is preloaded with Windows, it is not. And especially with your examples, because if we use the Copy on Write as a basis, then FireFox and EVERY Windows application that uses the Win32API is by definition 'pre-loaded' and has a smaller memory footprint, and that is totally out of context and crazy.
Do you use active desktop? I don't know about you, but I'm convinced leprechauns pre-render that for me while I sleep. The grandparent may not have been the most elegant speaker, but I think I understood what he meant, and I'm just some idiot.
Ok, Active Desktop is seldom used; however, EVEN if it is used, the HTML rendering DLLs are loaded in Explorer (the shell explorer not IE).
So when IE loads, it STILL has to load ALL the HTML rendering DLLs into the IE process. The 'only' advantage would be if the HTML DLLs would be in the system cache, but as for 'memory usage' or 'memory footprint' which is what this topic is about, IE loads ALL the DLLs in its process, it DOES NOT NOR CAN IT borrow them from the shell.
In Win98, IE could use the same process as Explorer, this has not been true now since WIn2k in 1999, yet people still believe that IE benefits from Windows having the HTML Dlls in the OS.
It would be like saying IE benefits from having the Truetype rendering DLLs in the OS as well, or the bitmap rendering DLLs in the OS. There are components the appliations on Windows can use, but differ from the HTML DLLs are they are NOT part of the core OS, as they are separate COM DLLs that each process has to open and LOAD.
Therefore, the IE memory footprint that taskmgr reports is INCLUDING all the HTML DLLs, just exactly like FireFox, and the load times should be equivalent as well, as both IE and FireFox have to load their HTML engines when launched. IE has NO advantages on Windows.
For an older example, see Mac OSX and the IE Version on OSX. It worked the same way, and still loaded fairly fast and used less memory when it was still being produced than several other browser on OSX. Yet you don't see people saying that IE had an advantage on OSX, yet it essentially worked the same way as it had to load its HTML rendering engine etc.
Go fact check this if you still don't understand. I am not here to say I have all the answers, but at the very least, if this interests you, go fact check it for yourself and don't believe me or the parent poster.
All I want to do is get the chance to get people to think and stop the Win98 thinking when they think of things like IE and Windows. It just cheapers the intellecutal input from the open source community when really bad information is spread as fact about Windows, and it gives Windows an advantage because it is underestimated because people believe these old facts.
What would be CONVINCING would be providing a SOURCE FOR YOUR CLAIMS that we can use to FIND OUT whether you know what you're talking about or not.
Ok, here are my sources... Learn how a process operates on Windows or goto www.microsoft.com and see how the IE process is isolated just LIKE any other application.
I give you the challenge to find the answers if you really don't know, it is up to you to find out who is the nutball, I am not here to spoon feed you programming or process and threads 101...
IE 7 could be called both good and bad to be a 'required' update.
Good
Security is much higher than IE6
IE7 supports CSS and XHTML 100 times better than IE6 so sites can start using them
Too many people still use IE6, and IE7 is better than sticking with IE6
Bad
Sites that use some of the 'old' IE6 hacks to make stuff work, will break
--- Actually, that might be a good thing
Companies that have used 'old' IE standards instead of moving forward with
compliance like XHTMl and CSS will face problems if their work arounds
Assume that IE7 is just like IE6. So some web sites need to be testing for
IE7 Now.
I think the good does out weigh the bad, as it will push users that are still using IE6 to get a more standards compliant browser. And it might even educate some of them, so they understand their browser has changed and explore other browsers as well. It will probably help Firefox downloads even.
The other thing this article seems to miss is that IE7 'will be forced' on users in Vista as well, so this will be good for Web Sites to get ready for the Vista Launch, because Vista simply does not do IE6. (And IE7 in Vista is like the stupid cousin, as it runs in protected mode on Vista, several levels below the user's own security even.)
MS has made a lot of big press about IE7, has supplied what it does and doesn't do to developers and beta testers for a long time now, and any reasonable web site administrator or developer should already be ensuring that their sites doesn't assume IE7 is as stupida s IE6 and make things fail.
It would be different if the IE7 list of supported standards, and testing of the Browser itself was not widescale. It has been available almost a full year before its release date, and if that is not enough time for web sites to rip out the crap IE6 kludge code, then maybe this will be a wake up call for them to do so.
MS fek'd up bad with IE6 and I still don't like that IE7 still maintains some backward compatibility for the IE tags, (hence why it won't pass the ACID2 test), but IE7 is the first push from Microsoft to support standards that are not only MS standards, and if anything we should welcome Microsoft and keep encouraging to do the right thing. (It might actually work.)
So in the end, we can start using more advanced CSS and XHTML concepts in the next year without having separate coding to make it display properly in IE6. We can also just send the users to Firefox or the IE7 download site and finally write sites like we should have been doing for a while now but couldn't because of the widespread use of IE6.
If you guessed IE then you win a footprint the size of New Hampshire. Thats right, all those DLL's and API's that have to preload for 5 minutes more than double Firefoxs load. And Firefox can do the same (if you enjoy monlithic load times) so that it can poreload as well.
Ok, I see this repeated and mindlessly repeated...
Windows DOES NOT preload IE, PERIOD... Get it?
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.
It would be like saying that because Windows has Fonts, that if Firefox uses the same fonts as the shell, then Windows is pre-loading Firefox as well. It is called process isolation. 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?
This is NOT Windows98 days anymore, and even on Win98, IE could be set to be a separate process. In Win2k and WinXP, IE is as foreign to the boot as Firefox, Winword or Photoshop. Please catch up to the year 2000 at least before posting your own FUD.
The next time I hear some idiot repeat that Windows preloads ANY of IE I will go off the deep end. This is stuff you CAN look up, should probably already know, and if you do know better and are repeating this crap to make FireFox look better, you are failing.
Any half bright developer would know all of this, yet it is repeated on Slashdot almost Daily.
It does not bode well when a company calls "computer manufacturers may add shortcuts to the start menu" a philosophical principle.
The strange thing about this statement, is MS has never restricted an OEM from putting literally anything on the start menu. (Have you seen some of the crap companies like Compaq and Dell load on computers?)
Now that I think about it, maybe MS would be better off if they 'did' limit this... (j/k)
Seriously, New Beta is more stable then Old Beta. A company takes the advice from beta testers and fixes issues the everyone complaines about. Congratulations M$, you have amazed us all again!
Actually it is a bit Hot... Not only Microsoft, but I have been involved with a lot of betas where builds would go down hill several times during the development cycle...
And there is also the stunning WindowsME example, it never got better.:)
Mac users in large part don't want to use Windows. As a Mac user, I wouldn't care if programs in Windows were significantly faster; I'd still have to use Windows to get that performance boost. And I'd rather use a slower Mac than faster Windows.
Very true of hard core Mac users. However, Apple is trying to break into new markets that have been Windows controlled. So if the person is an occasional Windows and occasional Mac user, they might buy the Mac for the cool 'hardware', but aren't married to either OS, so will lean to the Windows side.
This could work for Apple, but if the performance, especially in gaming (where a lot of families spend time) or even Photoshop is lacking, like WoW running 20% slower, the people will have cool Mac hardware, but be booting into Windows.
Also don't underestimate gaming if Apple catches up in other application performance. The gaming market tends to drive the 'high performance' computing purchases right now, and if Game vendors can make one version that will run best on the Windows side of even Mac hardware, they won't put out a Mac version.
Vista will also have an impact on this, as some of the application concepts taht developers and new software will be doing, just is not possible on any other platform at this point. (This is if Vista suceeds in expectations, but even if don't the XP gaming market is big and important to the casual families that is one of the Apple markets.)
Apple could very well end up becoming a Hardware company, they truly make more money off hardware than any of their software when contrasted with R&D.
But you are right, true Mac users won't give a crap about Windows performance, but it could lead to ISVs dropping the OSX versions of software and you will in the end be forced once again to boot into Windows for the latest game. (And this is already a problem for OSX that could increase multi-fold.)
One thing that could shift this is the level virtualization technology gets to, and allows full OS independant performance with OSes running side by side.
I personally don't want to see OSX become less important or cease to exist, and this looks a lot like a road of death that OS/2 took.
A reasonable CSS solution, even for Slashdot...
on
Dvorak Rants on CSS
·
· Score: 1
I know this will cause several people to gag...
Right now, one of the best WYSIWYG and code based CSS editors available is the new Microsoft Expression Web Designer. It is what our designers call, FrontPage, but with real standards and real power.
At least check out some of the demostration Videos if you have access to a Windows box. From what our tech and designers feedback, this product is not only about standards, but fully enforcing them, even if they break IE.
It can work with CSS in WYSIWYG mode with well done properly formatted coding. Also if you code by hand, the non-visual editor does the intellisense that many of us are use to in development IDEs.
From some of the demonstrations I have seen and the stuff our in house people have put out, it truly surprised the heck out of me, considering that it has a FrontPage heritage, which was about the opposite of what this product is about. Meaning that it adheres to standards and even forces developers to create well formed and compatible standards based XHTML and CSS.
So before you totally gag, it is worth taking a look at. And if you still gag, don't blame me, I don't profess it to be God's gift, but something that is free for now and quite respectible for ease of producing CSS and XHTML content without having to be a hard core standards nerd.
At the very least, MS may have some good ideas that some open source editors could learn from...:)
I don't think anybody believes Apple intends windows to be the primary OS on their hardware. However, it does make for an interesting comparison when windows and windows apps run faster on a Mac than a PC.
What will be most interesting is what Leopard has in store in the way of windows compatiblity. Some think Bootcamp functionality will no longer require a reboot.
The scary part for Apple is native Windows and native Intel OSX applications being compared.
So far, the Windows versions in Windows run faster on the new Macs than they do native Intel OSX apps under OSX. This could actually be an eyeopener for Apple and Mac fans. Benchmarks show that both Windows and even Linux for 'raw' application performance are faster than OSX applications on a new Intel Mac.
Gaming benchmarks also show that OpenGL applicaitons 'native Intel' run faster under Windows than OSX on the same hardware. And where possible to compare, games that also run under DirectX run even faster than the OpenGL version on Windows and significantly faster than the OpenGL version on the Mac. Something that will continue to make game developers just pump out a Windows only version and tell OSX users to boot into Windows to use the game.
(This could be the old OS/2 killing itself argument repeating itself.)
If the performance difference persists, Apple computer owners will be start flipping to Windows or Linux as the primary OS. If the next OSX release doesn't start to close this gap, (a gap of 10-40% difference) then Apple may end up with cool hardware, but egg on their face for OSX's lack luster performance
There is a difference between a conservative mindset and what the current 'so-called' conservative leaders are doing. This stretches beyond an ignorant assertion of the classic 'more informed public servant' knowing the needs of the people better than the people.
This spans a repeated disregard for any legality or responsibility that doesn't fit their ideals or agenda. This is not about having representatives and an administration that 'knows' better than the people this is about authoritarian worship, along the lines of the Nixon apologists to the Stalin and Hitler justifiers.
If you want to follow a conservative mindset, I suggest picking up a book by John Dean or other 'real' conservatives that are open for honest conservative debate, and don't fall in line to worship the idiot in chief.
You are bastardizing the conservative ideals yourself by associating them with what the current republican leadership is doing to dismantle basic principles this country was 'once' respected for and found by.
Well, I'm not just a Slahdot poster, I'm also someone who makes purchasing decisions for my company; and *I* say that one day of vulnerability for my production machines is one day too many. The customer has spoken.
Ok, enjoyed your humor and all...
However, if this is your baseline for your systems, a product doesn't exist that will 'always' meet this requirement.
If you factor in the timeline and statistics, chances are no matter what routers you are using, what OSes you are using, there are probably 20-50 exploits in existence with your systems at any one time. Just because they haven't been found, doesn't mean they are not there.
So as you apply your next round of patches to OSes, devices, etc... Just remember that the patches you are applying are for expoits that have been open for the entire lifecycle of the product. A scary fact... This is why I find it a bit distrubing to accept the 'shout the exploit' from the trees approach as a great rule, because it really doesn't work in the real world. All it does is alert hackers to new methods that they could be using on your systems right now.
Go back to the Rootkit joke, this is also something to consider. What if the exploit that is reported to MS is a new concept of hitting systems, MS fixes and tells Apple, Sun, others of the potential risk. Now the dork that figured it out goes on a spree gaining fame stating he is the one that found a hole in a MS product and how it works. Great, until the rest of the idustry realizes that it is something that affects every other OS out there, and only ones that had time to investigate this technique and protect against it is MS. Apple, Sun, and all the *nix are now compromised.
I agree MS can be slow, but people seem to discount the 100s of millions of appliations that run on Windows, as is it not only an OS, but a development platform that a LOT of software and code work in and around. So sure they have more people to throw at it, but the number of 3rd party support they have to keep their OSes running for is astronomical. In a way the 3rd party application base for MS OSes is too big for MS itself.
Even Linux and BSD with adoptation and 3rd party software reliance is starting to see a greater magnitude of possible downstream problems any change could make. This is great when geeks can recompile and update, but as these OSes become more of a commercial product platform, this will become as big of a problem for them as it is for Microsoft.
With these two points in mind, you seem to think every solution or bug or exploit is something that is 'find the bad code, fix it, test, publish'... This is not the case in the security world, where not only are bugs and exploits found that are easily fixable, but vast new ways of compromising systems are ALWAYS being developed that may take part of a kernel in an OS to be re-engineered, etc.
Look at SP2 for WindowsXP. This was a major publish as it took the latest attack techniques used on OSes and software and applied them across the OS. This massive patch could not have been created in a day, as it even required new compiler technologies to combat some of the new injection and other techniques starting to be used.
I like your 1 day concept, but I still don't see it working in the real world. It might make you feel safer at night, but truly you aren't nor is it realistic with large scale software.
Not sure if you were purposely missing my point, or were just adding more info.
A policy blocking the use of the Folder lock application would be 'easy' to implement as easy as creating a local or AD Recovery Agent.
The people yelling about this the most are the 'least' likely to be running with well defined AD policies with EFS Agents set or might not even be running under a AD environment. (Think mom and pop organizations too.)
BTW, you do realize that the EFS Recovery Agent 'does not' require AD? It can be setup on stand alone computers as well as be set enterprise wide with AD...
Another pitfall, is businesses that don't set this up until after a key employee has left and 'already' encrypted their files, finding out the hard way they should have been paying attention to EFS and options for limiting it or adding in the Admin user key to the mix.
This, just like locked Zips or tons of other sample technologies are out there, hence why I don't see how enterprise users would scream about the private folder application unless they maybe don't fully understand that this is one of the tiny forms of problems they could have with users encrypting data in one format or another.
You captured my first thoughts when I saw the product, let alone all the goofy press.
I can lock (password protect) a Zip or other file format and no one can easily get into it, why doesn't that create a major problem for companies?
The other thought after all this mess was... Ok, Windows with NTFS does encryption, and it is user based encryption. So if I encrypt folder on my desktop, even if an 'administrator' would take control of the file permissions for my desktop, the encrypted data is still not accessible.
Are people/companies so stupid they don't realize this stuff is already there? Do they hide the encyption features from their employees? And if so, then just drop a company policy on the servers telling the clients to not allow the MS 'private folder' program to install or run, case solved.
This has been one of the stupiest and craziest stories in a long time, and for goodwill with the corporate 'dimwits', MS kowtowed and even pulled the tool from their website. MS should have just posted information about other things like Zips, Encryption with NTFS and slapped the corporate ignorance up side the head....
This is both a response to you and the post above...
This brings up another issue. MS is big... All it takes is one bad person to take the report, read the bug/report or email and the report isn't going anywhere.
I have dealt with similar issues, as everyone here has, with every company. Whether it be customer service, to sales, to beta testing. Get the wrong moron on the other end of the phone or your email and the problem never gets addressed.
What responsibility does the person 'preparing to publish the bug' have to keep telling or communicating with MS or any Vendor about the issue? Add in the human factor, what if he secretly hopes they don't fix it, so he can post the bug, and get 'press' and hits and fame for it? Greed is dangerous.
So sure MS should have internal responsibility on this issue, but can every company afford to do so? What if a nut calls my secretary instead of our hotline, she goes mad, quits or jumps off the roof, then the bug is out there and my customers are at risk.
Sure these are bit crazy extremes, but all it takes is one to fall through the cracks in a company the size of MS, or even a disgruntled employee, and millions of people's computers are put at risk?
So in this senerio is the public disclosure the only method, or should the person that finds the problem be held a bit more accountable as well? Especially if they do not publish or submit the found bug anonymously and gain fame or $$$ from it falling through the cracks?
What incentive do they have other than 'being a good guy' do they have to report the bug properly and not just go for the fame? In viruses we know that finding a virus and getting paid was a bad idea (as people were writing them to collect the money), but would reward systems work for exploits if the people remain anonymous in some standardized 'community' timeframe?
As much as I don't like vendors not fixing the exploits I hate the people that use them for personal gain as well, when it could be at the cost of a lot of consumers.
If you are 'doing the right thing' you probably don't need your name in the headlines, or have that be part of your goal.
Reading http://browserfun.blogspot.com/ [blogspot.com], it looks like he submitted these on March 6. He is publically reporting them in July. That's three months.
Ok, but don't you think 3 months could even be a little short?
Take the distribution cycle of an average product. (Think outside MS for a second and imagine getting updates out to clients? Ouch.) Ok, back to Microsoft, even with Microsoft's Update Site and Automation, the rollout of an update like this would be a couple of weeks for users that were connected. Then you have corporate 'dimwit' policy, when they only do monthly updates to systems. So this adds to the timecycle to a week to a month depending on release.
So in real world, this gives MS two months to find the exploit, see if it is a design flaw, bug, etc, and find a fix that may or may not affect a mass of other interdependancies...
So what if this were not a 'browser' bug, but something that was later found to be a lower level exploit in the kernel level. (Heck even remember the Win32 WMF exploit?)
So if you have something at a low level, take even something that can move fast, pick your favorite *nix, do you honestly see a widespread 'major' kernel update getting done, tested, out to all the distributions, tested again, and out in three months?
In this senerio MS or any vendor would have a HELL of a lot of testing even after the exploit is tied up, and lot of vendors to report back and confirm that the majority of applications businesses depend on don't break because of a major change.
Also remember in terms of compatibility, you aren't just dealing with the main vendor like MS or Sun or Apple, you are dealing with every CRAZY 3rd party application that might be dependant or poking its head into that portion of the OS even if it shouldn't be.
I'm not truly saying your wrong here, just questioning if 3 months should really be seen as a 'long timespan' in the scope of things? Again, someone outside the vendor would not know how deep the exploit might go.
In reference to 'if the bug exists people are at risk' thinking, this is a statistics issue. Sure the vulnerability 'potentially' exists for millions of users, but widespread knowledge of 'how to use the exploit' is where damage really occurs. It is like the Sony Rootkit joke here, some 'hackers' never even thought down that road to root below and OS level, yet the widespread knowledge may have done more harm than the potential exploit would ever have in the first place.
There is a statistical difference between a wide known exploit with documentation of how to use it maliciously, and a conceptual exploit or potential exploit. Again, back to numbers and risk assessment. And if you go with just Stats, the guy pointing out the bug before the vendor creates a fix has just blown the numbers to the other side of the argument.
I concpetually do agree with the public disclosure might move vendors to act faster, but that is more of a perfect world ideal that I would like to see vendors live up to, but when reality hits, I'm not so sure it would be enough of a shift.
All it would take is one massive bug the vendor couldn't get patched fast enough to destory a portion of the computing industry. And one slipping through is our reality and not the perfect world I wish it was.
This less than perfect world, is also where I see a flaw in the open source model at times, just because most of us working in open source projects don't want to harm our own interests, does not mean there are people out that don't exist that would just to gain a bit of fame or revenge. So far the odds have been on the side of getting the patch out, but all it takes is one on enough in use computers and bingo, massive effects.
As you can tell in my response, I'm still knocking this marble around in my head, and the more debate on this we all can have the better off the industry will be by the people that don't stop thinking about this here.
Ok, this does seem strange, but brings more questions for myself...
First, lets assume he is reporting these to Microsoft in a responsible way...
With that said, who is he to 'determine' the 'timeline' for the fix? What if the bug or exploit affects a vast amount of code and third party applications? Does he get to hold the industry hostage becuase he didn't get the 'timeline' response or fix from Microsoft 'he' expects, when he knows nothing of what the bug or exploit might entail?
Microsoft 'should' also be keeping proper dialog with people that report these exploits, but that does not give one individual the 'button' to nuke MS when they don't jump on a fix as fast as the person wants, he is only screwing the consumers, not MS other than giving them bad press.
So if MS doesn't meet his timeline, then the consumers and industry gets screwed and put at risk.
If he 'had' the knowledge of all the downlevel code and testing to fix exploits that MS must undertake for each exploit, then sure he should be making the timeline call, but if the bug is more serious than what 'he' even may realize, it is still the Vendor that should have the say on publishing this information unless the person finding the 'exploit' can offer a credible fix, solution, or way to safe guard consumers.
This borders on yelling fire in a theater, because it isn't the theater owner that is getting hurt, it is the people getting trampled in the aisles...
Sure we all agree that MS should sometimes push up exploit fixes, but we also see others on here complain too much about MS addressing updates and fixes too rapidly if they break applications.
So I am left a bit conflicted over this..
Sure I can use another OS or another Browser, but there is a large base of 'consumers' that do use MS OSes and Browsers and they will be the least likely to even 'hear' of the exploit or protect themselves, instead this information will be gobbled up by the people that want to do harm to them and in the end the consumers get screwed.
Also of note, it isn't only MS this person has released information about when the vendor hasn't meet his timeline demands, and what are his standards based on what formula for what level of exploit and what level of code that would need to be fixed?
Does projects like Firefox and the Safari team have the resources to meet his timelines? How about distributions that spin off of other technologies that only have a small amount of people to work on them?
What are your opinions 'bias aside' on a single entitiy making decisions for vendors and consumers that they probably are not in a position to make?
Looking for honest debate because, I'm very curious to others views on this.
(Side Note) I also have been in a position much like this myself, finding holes that don't seem to be addressed on a timeline I would have liked...
Vista is also updated from the ground level up. New memory management, caching techniques, security protections, networking stack, audio stack, video driver ring move, etc etc etc...
It may not 'look' that much different, but has as many differences as NT4 to Win2k did.
I find articles like the one posted quite suspect. Legacy hardware can easily run WinXP as well, and there is Virtual PC for the hard core legacy apps that can be tightly wrapped in the new OSes security...
When will "professionals" realize that Word is not meant for all documents? It's great for short documents, posters, etc. But for real professional looking documents it's hard to beat a typesetter like TeX [or LaTeX].
When people figure out that character justification is the main feature Wordprocessor lack and how you can tell if a newspaper is using Word or a real publishing product for their articles.
Most people don't get it; however, the suggested products you list for replacements also have severe limitations.
For professional document publishing you should be using a desktop publisher, whether it is Quark, InDesign, or eve MS Publisher...
Ok, I'm skipping the first part of your article to respond to because I understand the storage and the capabilities of both UTF-8 and UTF-16, and what I am saying has nothing to do with even a 64K limit.
Both UTF-8 and UTF-16 are variable length if needed and can support characters far beyond a 16bit characterset. I think most people know this. Although by your statements, you seem to think UTF-16 is fixed, when it is also variable (a lot of people don't know this about UTF-16 though, so that is ok.)
I'm also wondering if perhaps you are confising UTF-8 with "8 bits per character", which obviously cannot store more than 256 characters.
UTF-16 is very misleading since there is a temptation to treat it as though each word is a glyph like UTF-32. This seems to be what you are thinking, and that is wrong. I do find it annoying that you are saying I have a "western bias" when in fact your ideas are the ones that make all the Chinese characters not work!
If this is what you are still seeing after reading my entire post then either I am not communicating well or you are failing to comprehend.
So you are saying that with UTF-16, that Chinese characters wil not work? Really?
So you are saying that UTF-8 is the 'accepted' standard, and yet in my work with foreing localization, many Asian speaking people would like to stick the UTF-8 in a place I care not to say.
UTF-16 is an extension of USC-2 and there is a 'reason' it was created, it does support 'language characters' and constructs taht UTF-8 does not, and it is far more efficient for Asian characters. It is also more efficient in handling western character sets because it is not restricted to big-eidian like UTF-8 is. (Since UTF-16 can go 'both ways' in this regard you would think it would be the natural choice for any OS that is multi-platform.
I really don't have time to fully explain this to you, and I suggest you do a bit more reasearch about language and the reasons behind the Unicdoe specifications that require 'surrogate pairs' and why UTF-16 is a long term Unicode solution and goal, and UTF-8 was bascially only allowed because of its efficiency in 'transmitting' western character sets because of the byte store size the ASCII correlation.
You aren't stupid on this subject, but there is a 'bigger' picture you are missing, and I feel sorry I don't have the time to fully articulate it and provide the links to help you with this.
Here is a hint to get you started, other languages 'glyph' pariing creates new characters that have no relation to the meaning of the single characters that are paired... In UTF-8 this is lost.. Also go look up more on UTF-8 storage in regard to Asian scripts, and see how it become less efficient than UTF-16.
Heck even go to the standards pages and read their view points on this stuff, I remember they used to have quite a resource with regard to language character sets and why and what portions of Unicode implmentations worked.
If you continue to assert that UTF-8 is BETTER than UTF-16, then you have an entire Unicode Standards body that very much DISAGREES with you. UTF-8 was quick, dirty and 'allowed' but because it lacks full Unicode concepts in support, it is just a transition encoding, period.
You seem knowledgeable, most of the responses anymore are people that only know Wikipedia or fact sheets from a Linux vendor site.
You write with such knowledge, but everything you write is from a very biased western character set perspective, which is also something that is still way to strong in the *nix doctrine.
Yes UTF-8 can be more efficient with text that has many ASCII conunterparts since it mimics ASCII's code set.
Surrogate pairs - I know you disagree, but I will assert, they ARE important, think outside western character sets and western thinking, go to Asian scripts for a minute for perspective on this.
Surrogate pairs ARE needed and this is why true Unicode buff will explain that UTF-8 is considered a 'quick' hack to implement 'MOST' of Unicode, but not a complete handling of Unicode.
Additionally, the unicode standard DICTATES that all true Unicode implementations understand and handle Surrogate pairs. UTF-8 was great for our period in history with bandwidth considerations and the predominance of English on the Internet; however, when doing 'real world' Unicode support, by NOT supporting at least USC-2 or UTF-16, it is a bastardization of Unicode.
There are a few other important items you are skipping, other than your western character set bias. When it comes to actually 'processing' Unicode (encode/decode), because of the nature of the x86 architecture, for performance of large text you USE UTF-16, which now even applies to OSX.
UTF-16 is just an extension of UCS-2 that adds in variable lengths. UTF-8 is a way to get Unicode characters, but at the cost of non-western character sets.
Another note of performance and considerations for localization, UTF-8 can be made to work in Asian markets, but there are hacks to get around the vast character sets and pairing.
Additionally, because of how UTF-8 stores Asian characters, UTF-16 is far more efficient and the 'proper' direction for handling Unicode. UTF-32 is the next progression, but it is still somewhat debatable how supportable the added benefits will ever be over a simple 16bit Unicode system like UTF-16.
You also act like MS made a mistake with USC-2 and UTF-16 implementations in their OSes, yet according to Unicode standards, they are the only main OS meeting the standards as defined and required for Asian characters. Isn't the open source world always yelling at MS for not FULLY complying with 'real' standards, yet MS is the only main OS vendor doing this with regard to Unicode... (I think Sun also pushes UTF-16, at least JAVA does.)
Like you say, sure UTF-16 is not as easy to code for as UTF-8 because of the byte order corruption that could occur, but I could also say that it is easier to just use plain ASCII because of less complexity as well, that doesn't mean that either meets the needs or functions as well as UTF-16.
MS also made a smart choice with UTF-16 because of its performance considerations in handling large amounts of data. UTF-16, unlike UTF-8, can be encoded for little-endian or big-endian depending on the target platform. (UTF-8 is big-endian.)
This is also very IMPORTANT when you consider that the MAJORITY of PCs out there are Intel or x86 based and use little-endian byte order. This gives UTF-16 not only an advantage in Asian text but also on the most common computing platform in the world, it also gets an additional performance edge.
So I'm not sure how this post turned into a 'lecture' on Unicode or why you easily buy into the UTF-8 is best because it is easy and fast because of its ASCII heritage. I do know this is a common myth in the *nix world, which is a little weird because of the 'open' nature of most *nixes and localization and non-western support should be a bit more important. Also since *nix has moved to the Intel and x86 realm in the past 10 years, it surprises me that the UTF-16 wouldn't have been adopted just for the performance gain of the little-eidian nature of the platform. Also what happens when Unicode standards f
First it isn't even accurate about what long file names are or how they are used.
Linux and OS X files have more character(s)
This actually isn't true, NTFS supports UTF-16 and full Unicode support. Most *nix FS are UTF-8 are they not? And last time I checked, a 16bit Unicode FS, has a LOT more potential characters, and why even Wikipedia uses NTFS as the 'example' of a how a FS should handle Unicode, since NT's design goals for localization were centered around complete Unicode support.
Secondly, it improperly states that NTFS cannot be case sensitive. By default, NTFS is not case sensitive for the Windows subsystem, but it can be enabled, also the *nix subsystems that run on NT can and usually are case sensitive to comply with the *nix subsystem conventions.
Third, people paint long filenames as bad thing or something to be used sparingly, but with the search tools and command like tools, even in OSes like XP and OSX, using long filenames has no significant difference to a short filename that does not outweigh the ambiguous nature of using shorter filenames.
And even with all the incorrect information, this article explains or teaches what? Nothing...
Slashdot Mirror
Now, please go learn about the 1990s technique of "filesystem caching". This means that the DLLs can effectively bepreloaded even if they are loaded by another process in another memory space. All that's needed is a memory copy from the cache and a relocation, which is much cheaper than a load from disk
Wow, while I'm learning this, maybe you can explain your awesome theory how this would in ANY way reduce the memory footprint of an application. Also go on to explain how because a file 'may or may not be cached' that the application would run faster and use less RAM.
Oh wait, that is another reality. Geesh...
PS, just so the other nerds won't tease you, it is NOT a 1990s concept, caching technology has been used for a LONG time before the 1990s.
From what I heard, Windows pre-loads the HTML rendering engine. IE is just a wrapper.
If Explorer loads the HTML COM objects they could in theory be in the File Cache. That is the END of the advantage or pre-loading. See www.microsoft.com
IE specifically runs in an isolated process, again see www.microsoft.com. (In Win98 it did not and ran shared.) In Win2k, it used the process and DLL isloation and WInXP even further extended this will full COM DLL isolation, meaning it ONLY has access to its only process and vise versa.
What this means is that IE when clicking the E icon, loads the ENTIRE HTML COM DLLS and Rendering Engine 'separately' into the IE process. Just like FireFox loads it HTML Rendering core when it is launched. They are fundamentally EXACTLY the same in this regard.
Wrong again. Memory is NOT duplicated for CODE and CONSTANT DATA. That would include fonts, too. What Taskmgr is reporting is the IE wrapper, plus internal page representation (DOM) of each open web page.
Yes and No. In the context of FireFox 'reporting' more memory as the post I was responding to, the reported memory in use is the same for IE and FireFox. IE has no advantage over any other application running on the Win32 platform. Both IE and FireFox take advantage of the platform and stuff like Window's core abilities to render fonts, Bitmaps and draw to the screen.
So while you are partially correct that there could be 'system' level shared APIs in use or a shared font, FireFox would HAVE THE SAME EXACT advantage that IE does in this regard.
Why? The IE HTML Rendering Engine is not a CORE OS API, it is a separate COM DLL set of technologies that are 'included and used by Windows' but not a core API or WIN32 OS component.
Understand?
This makes no sense. Please go study computer science and come back later.
Nice... And yet I have to give 101 level lessons just to get my point across to people that apparently only read the rumors or base their Windows Knowledge on Win98 concepts.
I don't have to explain myself, go look this stuff up if you really want to know. I truly am not responsible for anyone here getting it, but I would like to hope that I make a few people think and find these answers on their own instead of accepting old ideas or new myths.
(Sad note, after all my explaining that IE has no memory footprint advantage, I pull open Taskmgr to see that IE is consuming 56mb and Firefox is consuming only 32mb. So please explain the myth once again how IE has a memory advantage over Firefox? - Sadly, everyone's argument here makes FireFox look like a bloated piece of software, it isn't.)
Ok, you are off in left field here.
#1) DLLs can be shared, but the IE HTML COM objects are NOT shared, IE launches them in its own process. This shift was a security change in WinME and Win2k, that was even further extended in WinXP. IE 'could' in theory piggy back some of the HTML DLLs if another application like the shell had them loaded, but it 'specifically' DOES NOT for security reasons. (Go look this up, please. Do a google or a search on microsoft.com about COM isolation, also do a search on DLL isloation, and do a search on IE's Engine isloation from the OS.)
#2) Your assertions about DLL sharing and submitting that FireFox cannot use the Font sharing abilities of Windows are crazy. If ANY application is running under Windows and is writing to the screen in some matter, they are 'inherently' using the Win32 GDI+ API and 'shared' DLLs that all applications have access to, although there is distinction between shared core libraries and ones that are not.
#3) Your example of pushing code into another process is not needed, this is something that is well known by most people, and is not isolated to just Windows. It is something that Vista deals with in a way that shattering cannot allow process elevation. (Go look this stuff up.) Also this has NOTHING to do with whether Firefox or IE have a smaller memory footprint.
FireFox 'being a Win32' Application has JUST as much advantage to using the shared core OS DLLS as any windows application from Notepad to iTunes to Photoshop. I realize that some of the UI elements and programming in FireFox forgoes using some of the Windows APIs, but that is the FireFox teams decision and why cross platform applications often end up appearing slow and bloated and often uncompatibile with new OS releases because they do not adhere to the common UI structures or APIs provided.
This is true of FireFox running on KDE, OSX, or Win32. FireFox does employ 'some' optimizations on 'each' platform using the core OS, so FireFox is not Win32 free in any respect. For example it draws to the display context, it is using the standard Windows GDI APIs and DLLs as well.
The silliness in the responses I have seen are people are trying to define Firefox as sometihng it is and something it isn't, just as they are IE. Applications that run on ANY OS take advantage of the 'platform' available to it, the core or underlying APIs or Libraries that makeup the UI portion of the OS. (Yes we are sticking with GUI concepts here)
So Firefox can use any Windows TrueType Font, because it uses the WIndows Font API and therefore the Windows Font Rendering technologies. That is why you get cleartype in Firefox when running it on Windows, because it is LETTING Windows draw the fonts to its display bitmap, which is also something it is using Windows to maintain.
See, this is why I find your comment on the 'Fonts' as an example of something Firefox 'might not' have access to to be insane. Prove yourself wrong, next time you are at a Windows Machine, option the Option and change the Default rendering Font in FireFox to ANY Windows supported Font, and bingo, it will use that font, because it is LETTING Windows do the Font Rendering. Also notice that if cleartype is enabled, it is used and the Windows Font Hinting technology is also used.
FireFox is NOT at a loss of advantages when it comes to comparing itself to IE. If FireFox does eat more Memory (and sometimes it truly doesn't) then this is a problem with FireFox, not BECAUSE IE gets ANY special treatment in Windows.
Ok?
Copy on write. 'Nuff said.
Well it would be nice to go 'aha you are right' but sadly, it does not work this way. Sure there are caching and optimizations, but these are NOT shared DLLs in the context you are trying to paint them.
Copy on write optimizations have little bering on a separate isolated COM DLL rendering engine in Windows.
To use your example, we would have to assert that Firefox's Memory Footprint is less because it is 'also' pre-loaded and a part of Windows because it 'uses' the GDI+ of Windows for displaying Fonts and Bitmaps from the core OS APIs.
And that is quite a stretch.
I'm sure there are some low level CPU and caching operation that might help IE, but that is ONLY if a previous process has loaded the HTML rendering Engine.
And again, I will stress we are talking about the 'load times' and Memory footprint. The Memory reported by IE in the taskmgr is an accurate reflection of ALL the memory IE is using, including ALL the core HTML rendering DLLs.
So in this respect the memory footprint of IE is not reported any different than Firefox, nor does it have anything truly pre-loaded beyond the 'file caching' system, that by the time a system with low RAM gets to someone opening IE, has probably already paged out, and that is 'if' a previous applicatino has called IE rendering DLLs.
Quit trying to find 'excuses' for the crazy statement that the Windows Footprint is part of the IE footprint or that IE is preloaded with Windows, it is not. And especially with your examples, because if we use the Copy on Write as a basis, then FireFox and EVERY Windows application that uses the Win32API is by definition 'pre-loaded' and has a smaller memory footprint, and that is totally out of context and crazy.
Do you use active desktop? I don't know about you, but I'm convinced leprechauns pre-render that for me while I sleep. The grandparent may not have been the most elegant speaker, but I think I understood what he meant, and I'm just some idiot.
Ok, Active Desktop is seldom used; however, EVEN if it is used, the HTML rendering DLLs are loaded in Explorer (the shell explorer not IE).
So when IE loads, it STILL has to load ALL the HTML rendering DLLs into the IE process. The 'only' advantage would be if the HTML DLLs would be in the system cache, but as for 'memory usage' or 'memory footprint' which is what this topic is about, IE loads ALL the DLLs in its process, it DOES NOT NOR CAN IT borrow them from the shell.
In Win98, IE could use the same process as Explorer, this has not been true now since WIn2k in 1999, yet people still believe that IE benefits from Windows having the HTML Dlls in the OS.
It would be like saying IE benefits from having the Truetype rendering DLLs in the OS as well, or the bitmap rendering DLLs in the OS. There are components the appliations on Windows can use, but differ from the HTML DLLs are they are NOT part of the core OS, as they are separate COM DLLs that each process has to open and LOAD.
Therefore, the IE memory footprint that taskmgr reports is INCLUDING all the HTML DLLs, just exactly like FireFox, and the load times should be equivalent as well, as both IE and FireFox have to load their HTML engines when launched. IE has NO advantages on Windows.
For an older example, see Mac OSX and the IE Version on OSX. It worked the same way, and still loaded fairly fast and used less memory when it was still being produced than several other browser on OSX. Yet you don't see people saying that IE had an advantage on OSX, yet it essentially worked the same way as it had to load its HTML rendering engine etc.
Go fact check this if you still don't understand. I am not here to say I have all the answers, but at the very least, if this interests you, go fact check it for yourself and don't believe me or the parent poster.
All I want to do is get the chance to get people to think and stop the Win98 thinking when they think of things like IE and Windows. It just cheapers the intellecutal input from the open source community when really bad information is spread as fact about Windows, and it gives Windows an advantage because it is underestimated because people believe these old facts.
What would be CONVINCING would be providing a SOURCE FOR YOUR CLAIMS that we can use to FIND OUT whether you know what you're talking about or not.
Ok, here are my sources... Learn how a process operates on Windows or goto www.microsoft.com and see how the IE process is isolated just LIKE any other application.
I give you the challenge to find the answers if you really don't know, it is up to you to find out who is the nutball, I am not here to spoon feed you programming or process and threads 101...
IE 7 could be called both good and bad to be a 'required' update.
Good
Security is much higher than IE6
IE7 supports CSS and XHTML 100 times better than IE6 so sites can start using them
Too many people still use IE6, and IE7 is better than sticking with IE6
Bad
Sites that use some of the 'old' IE6 hacks to make stuff work, will break
--- Actually, that might be a good thing
Companies that have used 'old' IE standards instead of moving forward with
compliance like XHTMl and CSS will face problems if their work arounds
Assume that IE7 is just like IE6. So some web sites need to be testing for
IE7 Now.
I think the good does out weigh the bad, as it will push users that are still using IE6 to get a more standards compliant browser. And it might even educate some of them, so they understand their browser has changed and explore other browsers as well. It will probably help Firefox downloads even.
The other thing this article seems to miss is that IE7 'will be forced' on users in Vista as well, so this will be good for Web Sites to get ready for the Vista Launch, because Vista simply does not do IE6. (And IE7 in Vista is like the stupid cousin, as it runs in protected mode on Vista, several levels below the user's own security even.)
MS has made a lot of big press about IE7, has supplied what it does and doesn't do to developers and beta testers for a long time now, and any reasonable web site administrator or developer should already be ensuring that their sites doesn't assume IE7 is as stupida s IE6 and make things fail.
It would be different if the IE7 list of supported standards, and testing of the Browser itself was not widescale. It has been available almost a full year before its release date, and if that is not enough time for web sites to rip out the crap IE6 kludge code, then maybe this will be a wake up call for them to do so.
MS fek'd up bad with IE6 and I still don't like that IE7 still maintains some backward compatibility for the IE tags, (hence why it won't pass the ACID2 test), but IE7 is the first push from Microsoft to support standards that are not only MS standards, and if anything we should welcome Microsoft and keep encouraging to do the right thing. (It might actually work.)
So in the end, we can start using more advanced CSS and XHTML concepts in the next year without having separate coding to make it display properly in IE6. We can also just send the users to Firefox or the IE7 download site and finally write sites like we should have been doing for a while now but couldn't because of the widespread use of IE6.
If you guessed IE then you win a footprint the size of New Hampshire. Thats right, all those DLL's and API's that have to preload for 5 minutes more than double Firefoxs load. And Firefox can do the same (if you enjoy monlithic load times) so that it can poreload as well.
Ok, I see this repeated and mindlessly repeated...
Windows DOES NOT preload IE, PERIOD... Get it?
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.
It would be like saying that because Windows has Fonts, that if Firefox uses the same fonts as the shell, then Windows is pre-loading Firefox as well. It is called process isolation. 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?
This is NOT Windows98 days anymore, and even on Win98, IE could be set to be a separate process. In Win2k and WinXP, IE is as foreign to the boot as Firefox, Winword or Photoshop. Please catch up to the year 2000 at least before posting your own FUD.
The next time I hear some idiot repeat that Windows preloads ANY of IE I will go off the deep end. This is stuff you CAN look up, should probably already know, and if you do know better and are repeating this crap to make FireFox look better, you are failing.
Any half bright developer would know all of this, yet it is repeated on Slashdot almost Daily.
It does not bode well when a company calls "computer manufacturers may add shortcuts to the start menu" a philosophical principle.
The strange thing about this statement, is MS has never restricted an OEM from putting literally anything on the start menu. (Have you seen some of the crap companies like Compaq and Dell load on computers?)
Now that I think about it, maybe MS would be better off if they 'did' limit this... (j/k)
The sun is HOT!
:)
Seriously, New Beta is more stable then Old Beta. A company takes the advice from beta testers and fixes issues the everyone complaines about.
Congratulations M$, you have amazed us all again!
Actually it is a bit Hot... Not only Microsoft, but I have been involved with a lot of betas where builds would go down hill several times during the development cycle...
And there is also the stunning WindowsME example, it never got better.
Mac users in large part don't want to use Windows. As a Mac user, I wouldn't care if programs in Windows were significantly faster; I'd still have to use Windows to get that performance boost. And I'd rather use a slower Mac than faster Windows.
Very true of hard core Mac users. However, Apple is trying to break into new markets that have been Windows controlled. So if the person is an occasional Windows and occasional Mac user, they might buy the Mac for the cool 'hardware', but aren't married to either OS, so will lean to the Windows side.
This could work for Apple, but if the performance, especially in gaming (where a lot of families spend time) or even Photoshop is lacking, like WoW running 20% slower, the people will have cool Mac hardware, but be booting into Windows.
Also don't underestimate gaming if Apple catches up in other application performance. The gaming market tends to drive the 'high performance' computing purchases right now, and if Game vendors can make one version that will run best on the Windows side of even Mac hardware, they won't put out a Mac version.
Vista will also have an impact on this, as some of the application concepts taht developers and new software will be doing, just is not possible on any other platform at this point. (This is if Vista suceeds in expectations, but even if don't the XP gaming market is big and important to the casual families that is one of the Apple markets.)
Apple could very well end up becoming a Hardware company, they truly make more money off hardware than any of their software when contrasted with R&D.
But you are right, true Mac users won't give a crap about Windows performance, but it could lead to ISVs dropping the OSX versions of software and you will in the end be forced once again to boot into Windows for the latest game. (And this is already a problem for OSX that could increase multi-fold.)
One thing that could shift this is the level virtualization technology gets to, and allows full OS independant performance with OSes running side by side.
I personally don't want to see OSX become less important or cease to exist, and this looks a lot like a road of death that OS/2 took.
I know this will cause several people to gag...
:)
Right now, one of the best WYSIWYG and code based CSS editors available is the new Microsoft Expression Web Designer. It is what our designers call, FrontPage, but with real standards and real power.
http://www.microsoft.com/expression
At least check out some of the demostration Videos if you have access to a Windows box. From what our tech and designers feedback, this product is not only about standards, but fully enforcing them, even if they break IE.
It can work with CSS in WYSIWYG mode with well done properly formatted coding. Also if you code by hand, the non-visual editor does the intellisense that many of us are use to in development IDEs.
From some of the demonstrations I have seen and the stuff our in house people have put out, it truly surprised the heck out of me, considering that it has a FrontPage heritage, which was about the opposite of what this product is about. Meaning that it adheres to standards and even forces developers to create well formed and compatible standards based XHTML and CSS.
So before you totally gag, it is worth taking a look at. And if you still gag, don't blame me, I don't profess it to be God's gift, but something that is free for now and quite respectible for ease of producing CSS and XHTML content without having to be a hard core standards nerd.
At the very least, MS may have some good ideas that some open source editors could learn from...
I don't think anybody believes Apple intends windows to be the primary OS on their hardware. However, it does make for an interesting comparison when windows and windows apps run faster on a Mac than a PC.
What will be most interesting is what Leopard has in store in the way of windows compatiblity. Some think Bootcamp functionality will no longer require a reboot.
The scary part for Apple is native Windows and native Intel OSX applications being compared.
So far, the Windows versions in Windows run faster on the new Macs than they do native Intel OSX apps under OSX. This could actually be an eyeopener for Apple and Mac fans. Benchmarks show that both Windows and even Linux for 'raw' application performance are faster than OSX applications on a new Intel Mac.
Gaming benchmarks also show that OpenGL applicaitons 'native Intel' run faster under Windows than OSX on the same hardware. And where possible to compare, games that also run under DirectX run even faster than the OpenGL version on Windows and significantly faster than the OpenGL version on the Mac. Something that will continue to make game developers just pump out a Windows only version and tell OSX users to boot into Windows to use the game.
(This could be the old OS/2 killing itself argument repeating itself.)
If the performance difference persists, Apple computer owners will be start flipping to Windows or Linux as the primary OS. If the next OSX release doesn't start to close this gap, (a gap of 10-40% difference) then Apple may end up with cool hardware, but egg on their face for OSX's lack luster performance
There is a difference between a conservative mindset and what the current 'so-called' conservative leaders are doing. This stretches beyond an ignorant assertion of the classic 'more informed public servant' knowing the needs of the people better than the people.
This spans a repeated disregard for any legality or responsibility that doesn't fit their ideals or agenda. This is not about having representatives and an administration that 'knows' better than the people this is about authoritarian worship, along the lines of the Nixon apologists to the Stalin and Hitler justifiers.
If you want to follow a conservative mindset, I suggest picking up a book by John Dean or other 'real' conservatives that are open for honest conservative debate, and don't fall in line to worship the idiot in chief.
You are bastardizing the conservative ideals yourself by associating them with what the current republican leadership is doing to dismantle basic principles this country was 'once' respected for and found by.
Shame on you...
Well, I'm not just a Slahdot poster, I'm also someone who makes purchasing decisions for my company; and *I* say that one day of vulnerability for my production machines is one day too many. The customer has spoken.
Ok, enjoyed your humor and all...
However, if this is your baseline for your systems, a product doesn't exist that will 'always' meet this requirement.
If you factor in the timeline and statistics, chances are no matter what routers you are using, what OSes you are using, there are probably 20-50 exploits in existence with your systems at any one time. Just because they haven't been found, doesn't mean they are not there.
So as you apply your next round of patches to OSes, devices, etc... Just remember that the patches you are applying are for expoits that have been open for the entire lifecycle of the product. A scary fact... This is why I find it a bit distrubing to accept the 'shout the exploit' from the trees approach as a great rule, because it really doesn't work in the real world. All it does is alert hackers to new methods that they could be using on your systems right now.
Go back to the Rootkit joke, this is also something to consider. What if the exploit that is reported to MS is a new concept of hitting systems, MS fixes and tells Apple, Sun, others of the potential risk. Now the dork that figured it out goes on a spree gaining fame stating he is the one that found a hole in a MS product and how it works. Great, until the rest of the idustry realizes that it is something that affects every other OS out there, and only ones that had time to investigate this technique and protect against it is MS. Apple, Sun, and all the *nix are now compromised.
I agree MS can be slow, but people seem to discount the 100s of millions of appliations that run on Windows, as is it not only an OS, but a development platform that a LOT of software and code work in and around. So sure they have more people to throw at it, but the number of 3rd party support they have to keep their OSes running for is astronomical. In a way the 3rd party application base for MS OSes is too big for MS itself.
Even Linux and BSD with adoptation and 3rd party software reliance is starting to see a greater magnitude of possible downstream problems any change could make. This is great when geeks can recompile and update, but as these OSes become more of a commercial product platform, this will become as big of a problem for them as it is for Microsoft.
With these two points in mind, you seem to think every solution or bug or exploit is something that is 'find the bad code, fix it, test, publish'... This is not the case in the security world, where not only are bugs and exploits found that are easily fixable, but vast new ways of compromising systems are ALWAYS being developed that may take part of a kernel in an OS to be re-engineered, etc.
Look at SP2 for WindowsXP. This was a major publish as it took the latest attack techniques used on OSes and software and applied them across the OS. This massive patch could not have been created in a day, as it even required new compiler technologies to combat some of the new injection and other techniques starting to be used.
I like your 1 day concept, but I still don't see it working in the real world. It might make you feel safer at night, but truly you aren't nor is it realistic with large scale software.
Not sure if you were purposely missing my point, or were just adding more info.
A policy blocking the use of the Folder lock application would be 'easy' to implement as easy as creating a local or AD Recovery Agent.
The people yelling about this the most are the 'least' likely to be running with well defined AD policies with EFS Agents set or might not even be running under a AD environment. (Think mom and pop organizations too.)
BTW, you do realize that the EFS Recovery Agent 'does not' require AD? It can be setup on stand alone computers as well as be set enterprise wide with AD...
Another pitfall, is businesses that don't set this up until after a key employee has left and 'already' encrypted their files, finding out the hard way they should have been paying attention to EFS and options for limiting it or adding in the Admin user key to the mix.
This, just like locked Zips or tons of other sample technologies are out there, hence why I don't see how enterprise users would scream about the private folder application unless they maybe don't fully understand that this is one of the tiny forms of problems they could have with users encrypting data in one format or another.
You captured my first thoughts when I saw the product, let alone all the goofy press.
I can lock (password protect) a Zip or other file format and no one can easily get into it, why doesn't that create a major problem for companies?
The other thought after all this mess was... Ok, Windows with NTFS does encryption, and it is user based encryption. So if I encrypt folder on my desktop, even if an 'administrator' would take control of the file permissions for my desktop, the encrypted data is still not accessible.
Are people/companies so stupid they don't realize this stuff is already there? Do they hide the encyption features from their employees? And if so, then just drop a company policy on the servers telling the clients to not allow the MS 'private folder' program to install or run, case solved.
This has been one of the stupiest and craziest stories in a long time, and for goodwill with the corporate 'dimwits', MS kowtowed and even pulled the tool from their website. MS should have just posted information about other things like Zips, Encryption with NTFS and slapped the corporate ignorance up side the head....
Anyway, good post.
This is both a response to you and the post above...
This brings up another issue. MS is big... All it takes is one bad person to take the report, read the bug/report or email and the report isn't going anywhere.
I have dealt with similar issues, as everyone here has, with every company. Whether it be customer service, to sales, to beta testing. Get the wrong moron on the other end of the phone or your email and the problem never gets addressed.
What responsibility does the person 'preparing to publish the bug' have to keep telling or communicating with MS or any Vendor about the issue? Add in the human factor, what if he secretly hopes they don't fix it, so he can post the bug, and get 'press' and hits and fame for it? Greed is dangerous.
So sure MS should have internal responsibility on this issue, but can every company afford to do so? What if a nut calls my secretary instead of our hotline, she goes mad, quits or jumps off the roof, then the bug is out there and my customers are at risk.
Sure these are bit crazy extremes, but all it takes is one to fall through the cracks in a company the size of MS, or even a disgruntled employee, and millions of people's computers are put at risk?
So in this senerio is the public disclosure the only method, or should the person that finds the problem be held a bit more accountable as well? Especially if they do not publish or submit the found bug anonymously and gain fame or $$$ from it falling through the cracks?
What incentive do they have other than 'being a good guy' do they have to report the bug properly and not just go for the fame? In viruses we know that finding a virus and getting paid was a bad idea (as people were writing them to collect the money), but would reward systems work for exploits if the people remain anonymous in some standardized 'community' timeframe?
As much as I don't like vendors not fixing the exploits I hate the people that use them for personal gain as well, when it could be at the cost of a lot of consumers.
If you are 'doing the right thing' you probably don't need your name in the headlines, or have that be part of your goal.
I guess more questions from more questions...
Reading http://browserfun.blogspot.com/ [blogspot.com], it looks like he submitted these on March 6. He is publically reporting them in July. That's three months.
Ok, but don't you think 3 months could even be a little short?
Take the distribution cycle of an average product. (Think outside MS for a second and imagine getting updates out to clients? Ouch.) Ok, back to Microsoft, even with Microsoft's Update Site and Automation, the rollout of an update like this would be a couple of weeks for users that were connected. Then you have corporate 'dimwit' policy, when they only do monthly updates to systems. So this adds to the timecycle to a week to a month depending on release.
So in real world, this gives MS two months to find the exploit, see if it is a design flaw, bug, etc, and find a fix that may or may not affect a mass of other interdependancies...
So what if this were not a 'browser' bug, but something that was later found to be a lower level exploit in the kernel level. (Heck even remember the Win32 WMF exploit?)
So if you have something at a low level, take even something that can move fast, pick your favorite *nix, do you honestly see a widespread 'major' kernel update getting done, tested, out to all the distributions, tested again, and out in three months?
In this senerio MS or any vendor would have a HELL of a lot of testing even after the exploit is tied up, and lot of vendors to report back and confirm that the majority of applications businesses depend on don't break because of a major change.
Also remember in terms of compatibility, you aren't just dealing with the main vendor like MS or Sun or Apple, you are dealing with every CRAZY 3rd party application that might be dependant or poking its head into that portion of the OS even if it shouldn't be.
I'm not truly saying your wrong here, just questioning if 3 months should really be seen as a 'long timespan' in the scope of things? Again, someone outside the vendor would not know how deep the exploit might go.
In reference to 'if the bug exists people are at risk' thinking, this is a statistics issue. Sure the vulnerability 'potentially' exists for millions of users, but widespread knowledge of 'how to use the exploit' is where damage really occurs. It is like the Sony Rootkit joke here, some 'hackers' never even thought down that road to root below and OS level, yet the widespread knowledge may have done more harm than the potential exploit would ever have in the first place.
There is a statistical difference between a wide known exploit with documentation of how to use it maliciously, and a conceptual exploit or potential exploit. Again, back to numbers and risk assessment. And if you go with just Stats, the guy pointing out the bug before the vendor creates a fix has just blown the numbers to the other side of the argument.
I concpetually do agree with the public disclosure might move vendors to act faster, but that is more of a perfect world ideal that I would like to see vendors live up to, but when reality hits, I'm not so sure it would be enough of a shift.
All it would take is one massive bug the vendor couldn't get patched fast enough to destory a portion of the computing industry. And one slipping through is our reality and not the perfect world I wish it was.
This less than perfect world, is also where I see a flaw in the open source model at times, just because most of us working in open source projects don't want to harm our own interests, does not mean there are people out that don't exist that would just to gain a bit of fame or revenge. So far the odds have been on the side of getting the patch out, but all it takes is one on enough in use computers and bingo, massive effects.
As you can tell in my response, I'm still knocking this marble around in my head, and the more debate on this we all can have the better off the industry will be by the people that don't stop thinking about this here.
Ok, this does seem strange, but brings more questions for myself...
First, lets assume he is reporting these to Microsoft in a responsible way...
With that said, who is he to 'determine' the 'timeline' for the fix? What if the bug or exploit affects a vast amount of code and third party applications? Does he get to hold the industry hostage becuase he didn't get the 'timeline' response or fix from Microsoft 'he' expects, when he knows nothing of what the bug or exploit might entail?
Microsoft 'should' also be keeping proper dialog with people that report these exploits, but that does not give one individual the 'button' to nuke MS when they don't jump on a fix as fast as the person wants, he is only screwing the consumers, not MS other than giving them bad press.
So if MS doesn't meet his timeline, then the consumers and industry gets screwed and put at risk.
If he 'had' the knowledge of all the downlevel code and testing to fix exploits that MS must undertake for each exploit, then sure he should be making the timeline call, but if the bug is more serious than what 'he' even may realize, it is still the Vendor that should have the say on publishing this information unless the person finding the 'exploit' can offer a credible fix, solution, or way to safe guard consumers.
This borders on yelling fire in a theater, because it isn't the theater owner that is getting hurt, it is the people getting trampled in the aisles...
Sure we all agree that MS should sometimes push up exploit fixes, but we also see others on here complain too much about MS addressing updates and fixes too rapidly if they break applications.
So I am left a bit conflicted over this..
Sure I can use another OS or another Browser, but there is a large base of 'consumers' that do use MS OSes and Browsers and they will be the least likely to even 'hear' of the exploit or protect themselves, instead this information will be gobbled up by the people that want to do harm to them and in the end the consumers get screwed.
Also of note, it isn't only MS this person has released information about when the vendor hasn't meet his timeline demands, and what are his standards based on what formula for what level of exploit and what level of code that would need to be fixed?
Does projects like Firefox and the Safari team have the resources to meet his timelines? How about distributions that spin off of other technologies that only have a small amount of people to work on them?
What are your opinions 'bias aside' on a single entitiy making decisions for vendors and consumers that they probably are not in a position to make?
Looking for honest debate because, I'm very curious to others views on this.
(Side Note) I also have been in a position much like this myself, finding holes that don't seem to be addressed on a timeline I would have liked...
Vista is also updated from the ground level up. New memory management, caching techniques, security protections, networking stack, audio stack, video driver ring move, etc etc etc...
It may not 'look' that much different, but has as many differences as NT4 to Win2k did.
I find articles like the one posted quite suspect. Legacy hardware can easily run WinXP as well, and there is Virtual PC for the hard core legacy apps that can be tightly wrapped in the new OSes security...
When will "professionals" realize that Word is not meant for all documents? It's great for short documents, posters, etc. But for real professional looking documents it's hard to beat a typesetter like TeX [or LaTeX].
When people figure out that character justification is the main feature Wordprocessor lack and how you can tell if a newspaper is using Word or a real publishing product for their articles.
Most people don't get it; however, the suggested products you list for replacements also have severe limitations.
For professional document publishing you should be using a desktop publisher, whether it is Quark, InDesign, or eve MS Publisher...
Ok, I'm skipping the first part of your article to respond to because I understand the storage and the capabilities of both UTF-8 and UTF-16, and what I am saying has nothing to do with even a 64K limit.
Both UTF-8 and UTF-16 are variable length if needed and can support characters far beyond a 16bit characterset. I think most people know this. Although by your statements, you seem to think UTF-16 is fixed, when it is also variable (a lot of people don't know this about UTF-16 though, so that is ok.)
I'm also wondering if perhaps you are confising UTF-8 with "8 bits per character", which obviously cannot store more than 256 characters.
UTF-16 is very misleading since there is a temptation to treat it as though each word is a glyph like UTF-32. This seems to be what you are thinking, and that is wrong. I do find it annoying that you are saying I have a "western bias" when in fact your ideas are the ones that make all the Chinese characters not work!
If this is what you are still seeing after reading my entire post then either I am not communicating well or you are failing to comprehend.
So you are saying that with UTF-16, that Chinese characters wil not work? Really?
So you are saying that UTF-8 is the 'accepted' standard, and yet in my work with foreing localization, many Asian speaking people would like to stick the UTF-8 in a place I care not to say.
UTF-16 is an extension of USC-2 and there is a 'reason' it was created, it does support 'language characters' and constructs taht UTF-8 does not, and it is far more efficient for Asian characters. It is also more efficient in handling western character sets because it is not restricted to big-eidian like UTF-8 is. (Since UTF-16 can go 'both ways' in this regard you would think it would be the natural choice for any OS that is multi-platform.
I really don't have time to fully explain this to you, and I suggest you do a bit more reasearch about language and the reasons behind the Unicdoe specifications that require 'surrogate pairs' and why UTF-16 is a long term Unicode solution and goal, and UTF-8 was bascially only allowed because of its efficiency in 'transmitting' western character sets because of the byte store size the ASCII correlation.
You aren't stupid on this subject, but there is a 'bigger' picture you are missing, and I feel sorry I don't have the time to fully articulate it and provide the links to help you with this.
Here is a hint to get you started, other languages 'glyph' pariing creates new characters that have no relation to the meaning of the single characters that are paired... In UTF-8 this is lost.. Also go look up more on UTF-8 storage in regard to Asian scripts, and see how it become less efficient than UTF-16.
Heck even go to the standards pages and read their view points on this stuff, I remember they used to have quite a resource with regard to language character sets and why and what portions of Unicode implmentations worked.
If you continue to assert that UTF-8 is BETTER than UTF-16, then you have an entire Unicode Standards body that very much DISAGREES with you. UTF-8 was quick, dirty and 'allowed' but because it lacks full Unicode concepts in support, it is just a transition encoding, period.
You seem knowledgeable, most of the responses anymore are people that only know Wikipedia or fact sheets from a Linux vendor site.
You write with such knowledge, but everything you write is from a very biased western character set perspective, which is also something that is still way to strong in the *nix doctrine.
Yes UTF-8 can be more efficient with text that has many ASCII conunterparts since it mimics ASCII's code set.
Surrogate pairs - I know you disagree, but I will assert, they ARE important, think outside western character sets and western thinking, go to Asian scripts for a minute for perspective on this.
Surrogate pairs ARE needed and this is why true Unicode buff will explain that UTF-8 is considered a 'quick' hack to implement 'MOST' of Unicode, but not a complete handling of Unicode.
Additionally, the unicode standard DICTATES that all true Unicode implementations understand and handle Surrogate pairs. UTF-8 was great for our period in history with bandwidth considerations and the predominance of English on the Internet; however, when doing 'real world' Unicode support, by NOT supporting at least USC-2 or UTF-16, it is a bastardization of Unicode.
There are a few other important items you are skipping, other than your western character set bias. When it comes to actually 'processing' Unicode (encode/decode), because of the nature of the x86 architecture, for performance of large text you USE UTF-16, which now even applies to OSX.
UTF-16 is just an extension of UCS-2 that adds in variable lengths. UTF-8 is a way to get Unicode characters, but at the cost of non-western character sets.
Another note of performance and considerations for localization, UTF-8 can be made to work in Asian markets, but there are hacks to get around the vast character sets and pairing.
Additionally, because of how UTF-8 stores Asian characters, UTF-16 is far more efficient and the 'proper' direction for handling Unicode. UTF-32 is the next progression, but it is still somewhat debatable how supportable the added benefits will ever be over a simple 16bit Unicode system like UTF-16.
You also act like MS made a mistake with USC-2 and UTF-16 implementations in their OSes, yet according to Unicode standards, they are the only main OS meeting the standards as defined and required for Asian characters. Isn't the open source world always yelling at MS for not FULLY complying with 'real' standards, yet MS is the only main OS vendor doing this with regard to Unicode... (I think Sun also pushes UTF-16, at least JAVA does.)
Like you say, sure UTF-16 is not as easy to code for as UTF-8 because of the byte order corruption that could occur, but I could also say that it is easier to just use plain ASCII because of less complexity as well, that doesn't mean that either meets the needs or functions as well as UTF-16.
MS also made a smart choice with UTF-16 because of its performance considerations in handling large amounts of data. UTF-16, unlike UTF-8, can be encoded for little-endian or big-endian depending on the target platform. (UTF-8 is big-endian.)
This is also very IMPORTANT when you consider that the MAJORITY of PCs out there are Intel or x86 based and use little-endian byte order. This gives UTF-16 not only an advantage in Asian text but also on the most common computing platform in the world, it also gets an additional performance edge.
So I'm not sure how this post turned into a 'lecture' on Unicode or why you easily buy into the UTF-8 is best because it is easy and fast because of its ASCII heritage. I do know this is a common myth in the *nix world, which is a little weird because of the 'open' nature of most *nixes and localization and non-western support should be a bit more important. Also since *nix has moved to the Intel and x86 realm in the past 10 years, it surprises me that the UTF-16 wouldn't have been adopted just for the performance gain of the little-eidian nature of the platform. Also what happens when Unicode standards f
Really, and the point of this article?
First it isn't even accurate about what long file names are or how they are used.
Linux and OS X files have more character(s)
This actually isn't true, NTFS supports UTF-16 and full Unicode support. Most *nix FS are UTF-8 are they not? And last time I checked, a 16bit Unicode FS, has a LOT more potential characters, and why even Wikipedia uses NTFS as the 'example' of a how a FS should handle Unicode, since NT's design goals for localization were centered around complete Unicode support.
Secondly, it improperly states that NTFS cannot be case sensitive. By default, NTFS is not case sensitive for the Windows subsystem, but it can be enabled, also the *nix subsystems that run on NT can and usually are case sensitive to comply with the *nix subsystem conventions.
Third, people paint long filenames as bad thing or something to be used sparingly, but with the search tools and command like tools, even in OSes like XP and OSX, using long filenames has no significant difference to a short filename that does not outweigh the ambiguous nature of using shorter filenames.
And even with all the incorrect information, this article explains or teaches what? Nothing...