Slashdot Mirror
Domain: msdn.com
Stories and comments across the archive that link to msdn.com.
Comments · 3,271
-
Re:So much service!
http://blogs.msdn.com/xboxteam/archive/2006/02/17/534421.aspx
http://www.xbreporter.com/xbox_system_specifications.php
I was expecting to find more details, I don't wanna look around more than that. Seems like it uses it's own custom OS but based on various existing Windows technology. -
Re:Nothing needs to be done"Anyone except open source programmers, since the license for ooxml is incompatible with the GPL."
Huh, I didn't know that "open source programmers" == "GPL". There are many OSI licenses that ARE compatible with OOXML even if GPL is not. And I don't concede your point even regarding GPL, since Gnumeric implements OOXML with GPL code.
"As well, the patent situation is another large roadblock for open source (not to mention anyone else). So really, not just anyone can use it."
The patent provisions are the same as for ODF.
Jason Matusow has recently posted two blog entries regarding the IP issues regarding OOXML (and compares it with ODF, PDF, etc), which are very good reads. (Yes, he works for Microsoft, so you might just dismiss him as a liar, but if you're willing to read Rob Weir and Groklaw, and take what they have to say as unquestioned Gospel, you might want to at least take a look what the other side has to say; if anything it'll make your own arguments stronger in the future.)
More Open XML Discussion - more misunderstandings about standards and IP
IP, RAND, Standards, OSP, ISP - the conversation continues...
Here's an excerpt from the first blog entry:The ISO/IEC JTC 1 patent policy is applied uniformly to all standards in the ISO/IEC JTC 1 arena. The idea that the RAND declaration regarding Open XML is any different than a RAND declaration for ODF or for any other ISO Standard (such as...oh I don't know...how about PDF just for fun. Remember the huge list of patents that Adobe used to put on the welcome screen of the Acrobat reader alone?). The terms provided for the Microsoft patents in Open XML are legally irrevocable. They are global. Since they are broader than the RAND declaration for JTC 1, the attempt at FUD by the Groklaw post should be recognized for what it is...FUD.
Incidentally, both of the above blog entries point out that Linux distros already ship software under licenses that are incompatible with each other, making today's Linux distros technically illegal already. In the second blog entry, Jason goes on to say regarding this:
Legal snags like the ones I mentioned only matter if someone presses it in a court case. No one can say if these issues will ever become an issue but that has never stopped a single person from using Linux. So, when people then say that the MS OSP, or IBM's ISP, or RAND terms, or whatever means that Free Software developers can't develop something, I find it hard to take seriously when the intent, and all of the materials surrounding these actions speak of building bridges and enabling...not shutting down or threatening. Those same developers are willing to take those exact same issues as no concern on one hand and then scream foul on the other.
(BTW, regarding the GPL, I'll quote a comment made by 'hAL' to the second blog entry:
"Both the 'Interoperability Specification Pledge' from IBM (on for instance ODF v1.0/v1.1) and Suns 'Covenant Not to Sue' suffer from the same issue with GPL as Microsofts OSP licensing. GPL3 code can be reused outside the limits of those RAND licenses. Any patent protection by IBM and Sun on OpenDocument and from Micrsoft on OOXML will not apply if the GPL code is reused in a project that does not fall under those licenses. As Suns covenant only applies to OpenDocument reuse of patent protected code from an ODF code for anything else but an ODF implementation voids the covenant.")
Anyway, the post to which I replied talked of nobody being able to implement OOXML support besides Microsoft. He didn't say anything about "open source programmers", let alone "GPL". As long as there are other OOXML programs, even if they are closed source programs, ta -
Re:Nothing needs to be done"Anyone except open source programmers, since the license for ooxml is incompatible with the GPL."
Huh, I didn't know that "open source programmers" == "GPL". There are many OSI licenses that ARE compatible with OOXML even if GPL is not. And I don't concede your point even regarding GPL, since Gnumeric implements OOXML with GPL code.
"As well, the patent situation is another large roadblock for open source (not to mention anyone else). So really, not just anyone can use it."
The patent provisions are the same as for ODF.
Jason Matusow has recently posted two blog entries regarding the IP issues regarding OOXML (and compares it with ODF, PDF, etc), which are very good reads. (Yes, he works for Microsoft, so you might just dismiss him as a liar, but if you're willing to read Rob Weir and Groklaw, and take what they have to say as unquestioned Gospel, you might want to at least take a look what the other side has to say; if anything it'll make your own arguments stronger in the future.)
More Open XML Discussion - more misunderstandings about standards and IP
IP, RAND, Standards, OSP, ISP - the conversation continues...
Here's an excerpt from the first blog entry:The ISO/IEC JTC 1 patent policy is applied uniformly to all standards in the ISO/IEC JTC 1 arena. The idea that the RAND declaration regarding Open XML is any different than a RAND declaration for ODF or for any other ISO Standard (such as...oh I don't know...how about PDF just for fun. Remember the huge list of patents that Adobe used to put on the welcome screen of the Acrobat reader alone?). The terms provided for the Microsoft patents in Open XML are legally irrevocable. They are global. Since they are broader than the RAND declaration for JTC 1, the attempt at FUD by the Groklaw post should be recognized for what it is...FUD.
Incidentally, both of the above blog entries point out that Linux distros already ship software under licenses that are incompatible with each other, making today's Linux distros technically illegal already. In the second blog entry, Jason goes on to say regarding this:
Legal snags like the ones I mentioned only matter if someone presses it in a court case. No one can say if these issues will ever become an issue but that has never stopped a single person from using Linux. So, when people then say that the MS OSP, or IBM's ISP, or RAND terms, or whatever means that Free Software developers can't develop something, I find it hard to take seriously when the intent, and all of the materials surrounding these actions speak of building bridges and enabling...not shutting down or threatening. Those same developers are willing to take those exact same issues as no concern on one hand and then scream foul on the other.
(BTW, regarding the GPL, I'll quote a comment made by 'hAL' to the second blog entry:
"Both the 'Interoperability Specification Pledge' from IBM (on for instance ODF v1.0/v1.1) and Suns 'Covenant Not to Sue' suffer from the same issue with GPL as Microsofts OSP licensing. GPL3 code can be reused outside the limits of those RAND licenses. Any patent protection by IBM and Sun on OpenDocument and from Micrsoft on OOXML will not apply if the GPL code is reused in a project that does not fall under those licenses. As Suns covenant only applies to OpenDocument reuse of patent protected code from an ODF code for anything else but an ODF implementation voids the covenant.")
Anyway, the post to which I replied talked of nobody being able to implement OOXML support besides Microsoft. He didn't say anything about "open source programmers", let alone "GPL". As long as there are other OOXML programs, even if they are closed source programs, ta -
Re:Nothing needs to be done
"That should just about immediately eliminate OOXML, as I hear the biggest complaint was that there is parts of it that are just not implementable by anyone but Microsoft."
Yes, that's the propaganda that one hears constantly.
But Microsoft is creating an OOXML SDK that will make it easy to implement OOXML readers and writers. The April CTP of the SDK was just released last week and the complete version 1.0 of the SDK is scheduled for release next month.
http://blogs.msdn.com/erikaehrli/archive/2008/04/17/announcing-the-open-xml-format-sdk-april-ctp.aspx
So I'm afraid that OOXML opponents will have to come up with a new talking point. -
Re:SMB2 talkAre there any good NFS clients for Windows? Any that are free? Yes, there's Microsoft's own from their Services for Unix download or the Vista/2008 Subsystem for Unix applications.
-
Re:fubar
This interesting because he's exploiting a malloc fail. The gory details of exploiting ActionScript is also cool because it has a bytecode verifier and he manages to get around it. It really is a lot more high tech than a typical stack buffer smash against a badly written C application, and that is important because everyone should hopefully have updated that sort of code to be exploit free by now. And stack checked binaries and data execute prevention, AMD's "Not Execute" bit, make those more likely to end in process death than arbitrary code execution.
Finally because it works on both IE and Firefox and Flash has such a huge installation base it should be able to target a very high percentage of current machines. Larry Osterman called it "The way the world (wide web]) ends"
Mind you, if Address Space Layout Randomisation was turned on in the Flash executable on Vista, exploiting this hole would most likely (255 times out of 256) lead to a browser crash rather than arbitrary code execution, so it's not like the last few years work on security has been totally wasted. At the moment it's not and you will get owned reliably. Adobe have published an update, so it's a good idea to download it.
http://www.adobe.com/support/security/bulletins/apsb08-11.html
Back when I was reading about security someone said that buffer overflows that execute code on the stack were first generation exploits. Second generation would be more subtle stuff like this. -
Re:Isn't the whole idea of a standard
> This "standard" is completely irrelevant as a standard. No one, absolutely no one, is going to implement it. Not even Microsoft.
BS: Microsoft has pledged to support it in public. So assuming that the OpenOffice implementation of OOXML continues, it will support it too.
> No company is going to be allowed to implement it and become a competitive threat to Microsoft. Microsoft will shut them down with Patent Violations.
Again BS: The OSP pretty much crushes that arguement. Even the main point in the SFLC anaylsis about future versions has been addressed.
Your core arguements seem to be strictly Proof by Assertion -
XP runs fine on mine
Not sure why they need to create a cut down version of XP. It runs just fine on mine with hardly any tweaks. The real issue is the 4GB SSD but this is also an issue for the default Xandros distro it comes with.
I have XP Pro SP2 with all updates, WMP10, Winamp, MPC, ffdshow, Notepad++, UltraEdit, Office 2003 (Word and Excel only), mIRC, Windows Live Messenger, Total Commander, Firefox and a few other little single exe apps like PuTTY and still have 1.5GB of SSD left. It runs perfect. Boots quickly and is just as responsive as a "normal" laptop. I originally put Windows Fundamentals for Legacy PCs on my Eee as I have it from my Software Assurance contract with Microsoft however the lack of NULL driver gave me issues with Cygwin so I decided to just stick full XP on it and have not looked back. I can't see I have noticed any difference between full XP and WinFLP.
The dialog size issue pops up every now and then but it is very rare once the system is up and running. The only screen I found was an issue is the 'System Properties' screen (WinKey+Break or System in the Control Panel). However as all these screens default to the OK button you can just hit enter to confirm or Esc to cancel. Pretty simple.
It also seems a little too late for Microsoft to do this. I mean by the time they get around to releasing it the 4GB SSD issue will be history as 8+ GB SSD will be the norm (the Eee 900 has 12 and 20GB models from what I have read and are due out very soon).
The only tweak I have done is move %TEMP% to an SDHC card however it made no difference to the performance (at least that I can tell) and was done just to save the SSD from being used as scratch space. I also stuck the Mozilla temp files on the SDHC too. However everything else (pagefile included as sticking it on the SDHC slowed the machine down) is on the SSD.
It would make more sense to me if Microsoft took Vista and stripped bits out of that. There are a lot of people who have done this and are very happy with Vista on their Eee. Ben Armstrong (Virtual PC PM) has done just this, have a read at http://blogs.msdn.com/virtual_pc_guy/archive/2008/03/05/using-virtual-pc-to-evaluate-eee-pc.aspx -
Re:I suspect that..."If OOXML was a clean standard that could be implenmented freely then i woud stop complaining about it." Yeah, like YOU are going to implement either OOXML or ODF. LOLOLOL The fact is, many have implemented Ecma OOXML to one extent or another, and they will update their software to implement ISO OOXML. And those that need help can use Microsoft's upcoming OOXML SDK.
But for YOU to talk about your complaining that you can't implement it is too funny. You couldn't implement "Hello World" to save your life, and you think that ISO standards should be subject to "Can peragrin implement it?" test? We'd have no standards at all!! -
Re:Personal Attacks?OOXML would fail requirements 2 (AutoSpaceLikeWord97, VML etc.), 3 (date representations), 4 (VML vs. SVG) and 5 (the OOXML spec has no implementations in the wild; the Office 2007 format does not match the spec). I'm not sure about requirement 1, but it's possible that OOXML fail that as well. You, like most slashdotters, are completely unaware of what changes were made between ECMA's OOXML and the recently approved ISO OOXML.
First, the "AutoSpaceLikeWord97" issue has been fixed. AutoSpaceLikeWord95 and the like have now been fully spec'ed and placed in the "transition conformance" section (i.e. those behaviors are deprecated, only for use in old documents).
See the AutoSpaceLikeWord95 section of this page.
And see supressTopSpacingWP, for example
Second, ISO OOXML spreadsheets have only one date format, the ISO 8601 date format. And the Lotus leap year bug behavior has been deprecated, only for use by old spreadsheets (that may rely on that behavior either implicitly or even explicitly). Moreover, ISO OOXML's date format is now simpler than ODF's.
Resolution of OOXML spreadsheet dates issue
Third, VML has also been deprecated, and new documents are only to use DrawingML. But you cite SVG; the thing about that is that what ODF calls "SVG" isn't actually SVG. ODF extends SVG's features, cuts lots of SVG's features, and changes the behavior of other SVG features, so that one cannot just use an SVG library to implement ODF's "SVG" functionality and call it done.
Embrace and extend - SVG in ODF revisited
Finally, of course, there are not yet any ISO OOXML implementations in the wild. But there aren't any full implementations of ODF in the wild either. Here's a list of ODF apps, scored on their ODF functionality, and no app achieves a perfect score, not even OO.o.
http://opendocumentfellowship.com/applications
In summary, many here talk of how horrible OOXML is by citing problems that have been resolved in the approved ISO revision. (I'm amazed that so many here are under the illusion that the problems cited with ECMA OOXML weren't addressed at all in the final ISO version. Under that misunerstanding, I can see where one might be tempted to believe that NO votes switching to YES votes could only be the result of bribery and corruption.)
Many here also are blissfully (willfully?) ignorant of ODf's own problems. I've almost NEVER seen a post, let alone an article, on ODF's problems, like its bastardization of SVG. For example, people here cite ODF's use of "SVG" as a virtue, unaware that ODF's "SVG" isn't really SVG. -
Re:Personal Attacks?OOXML would fail requirements 2 (AutoSpaceLikeWord97, VML etc.), 3 (date representations), 4 (VML vs. SVG) and 5 (the OOXML spec has no implementations in the wild; the Office 2007 format does not match the spec). I'm not sure about requirement 1, but it's possible that OOXML fail that as well. You, like most slashdotters, are completely unaware of what changes were made between ECMA's OOXML and the recently approved ISO OOXML.
First, the "AutoSpaceLikeWord97" issue has been fixed. AutoSpaceLikeWord95 and the like have now been fully spec'ed and placed in the "transition conformance" section (i.e. those behaviors are deprecated, only for use in old documents).
See the AutoSpaceLikeWord95 section of this page.
And see supressTopSpacingWP, for example
Second, ISO OOXML spreadsheets have only one date format, the ISO 8601 date format. And the Lotus leap year bug behavior has been deprecated, only for use by old spreadsheets (that may rely on that behavior either implicitly or even explicitly). Moreover, ISO OOXML's date format is now simpler than ODF's.
Resolution of OOXML spreadsheet dates issue
Third, VML has also been deprecated, and new documents are only to use DrawingML. But you cite SVG; the thing about that is that what ODF calls "SVG" isn't actually SVG. ODF extends SVG's features, cuts lots of SVG's features, and changes the behavior of other SVG features, so that one cannot just use an SVG library to implement ODF's "SVG" functionality and call it done.
Embrace and extend - SVG in ODF revisited
Finally, of course, there are not yet any ISO OOXML implementations in the wild. But there aren't any full implementations of ODF in the wild either. Here's a list of ODF apps, scored on their ODF functionality, and no app achieves a perfect score, not even OO.o.
http://opendocumentfellowship.com/applications
In summary, many here talk of how horrible OOXML is by citing problems that have been resolved in the approved ISO revision. (I'm amazed that so many here are under the illusion that the problems cited with ECMA OOXML weren't addressed at all in the final ISO version. Under that misunerstanding, I can see where one might be tempted to believe that NO votes switching to YES votes could only be the result of bribery and corruption.)
Many here also are blissfully (willfully?) ignorant of ODf's own problems. I've almost NEVER seen a post, let alone an article, on ODF's problems, like its bastardization of SVG. For example, people here cite ODF's use of "SVG" as a virtue, unaware that ODF's "SVG" isn't really SVG. -
Re:you, my friend, made an incorrect assumption...
But people aren't paying for something they could get 'for free'. Windows is a very different thing to Linux. Go read The Old New Thing for why in detail. Raymond Chen describes a mindset - that new releases of the OS should support old software even if it is buggy, that software interfaces are contracts that should not be broken, and that software designers should make choices for their users rather that presenting them with a load of questions they cannot possibly answer. That's completely missing in the 'free software' world. I've installed Linux a couple of times, fiddled around for a couple of weeks until all the bits of my PC more or less work. But they never work as well as they did in Windows. Eventually I end up nuking it and reinstalling Windows because the Linux 'equivalent' of some Windows applications I use all the time is completely amateurish and user hostile.
And they are not paying very much. Suppose I buy a laptop for $1500. It comes with a copy of Windows which costs say $50 to the PC vendor (I read an article somewhere that estimated the cost of Windows to Dell was $50). But the PC vendor will install a load of trialware on it that I need to uninstall. My guess is that they get paid a kickback for doing that because a percentage of people will buy it at the end of the trial. So the effective cost of Windows is probably less. Under $50 every time I buy a new PC every three years is not a lot of money. Hell I'd pay a lot more to avoid the dreaded Linux fault threshold if I had to. -
Re:It runs fine on Intel graphicsI've used Vista on a laptop with Intel graphics and it runs just fine.
It's just image composition, Intel chips can manage that.
What exactly is the difference on a high-end graphics card? In terms of graphics cards; if you can run Windows Aero then their really shouldn't be any noticeable difference (as only modern graphics cards will be able to support Aero [like those supporting Pixel Shader 2.0]). If you wanna play games, then that's another story (and a wholly different topic), but for just running Windows Aero in a desktop environment then you should be good-to-go.
For more information:
http://en.wikipedia.org/wiki/Windows_Aero#Requirements
And although not usually apparent to me when I search for technical details on Google (I can presume Web sites don't heavily reference these sources); http://channel9.msdn.com/ and the M$ programmer blogs are a wealth of technical information (http://blogs.technet.com/default.aspx), though it may be easier to use http://www.google.com/microsoft.html to search for these Microsoft blogs -
Re:Why is parent flamebait?
MS has NEVER done anything yet that is pro open source.
What about the 700 CSS testcases they recently contributed to the W3C under the BSD license? Or any of their other releases under OSI-approved licenses, for example WIX? Are you seriously going to argue that releasing things under open-source licenses is not pro-open-source?
-
Re:Or Unix or Mac ...stop that stupid behavior (return to farking ini files in the app directory instead of the incredibly stupid registry) and stop installing 65,000 random dll's in the system directories.
11 reasons why the registry is better than
http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx* INI files don't support Unicode. Even though there are Unicode functions of the private profile functions, they end up just writing ANSI text to the INI file. (There is a wacked out way you can create a Unicode INI file, but you have to step outside the API in order to do it.) This wasn't an issue in 16-bit Windows since 16-bit Windows didn't support Unicode either!
* INI file security is not granular enough. Since it's just a file, any permissions you set are at the file level, not the key level. You can't say, "Anybody can modify this section, but that section can be modified only by administrators." This wasn't an issue in 16-bit Windows since 16-bit Windows didn't do security.
* Multiple writers to an INI file can result in data loss. Consider two threads that are trying to update an INI file. If they are running simultaneously, you can get this:
Thread 1 Thread 2
Read INI file
Read INI file
Write INI file + X
Write INI file + Y
Notice that thread 2's update to the INI file accidentally deleted the change made by thread 1. This wasn't a problem in 16-bit Windows since 16-bit Windows was co-operatively multi-tasked. As long as you didn't yield the CPU between the read and the write, you were safe because nobody else could run until you yielded.
* INI files can suffer a denial of service. A program can open an INI file in exclusive mode and lock out everybody else. This is bad if the INI file was being used to hold security information, since it prevents anybody from seeing what those security settings are. This was also a problem in 16-bit Windows, but since there was no security in 16-bit Windows, a program that wanted to launch a denial of service attack on an INI file could just delete it!
* INI files contain only strings. If you wanted to store binary data, you had to encode it somehow as a string.
* Parsing an INI file is comparatively slow. Each time you read or write a value in an INI file, the file has to be loaded into memory and parsed. If you write three strings to an INI file, that INI file got loaded and parsed three times and got written out to disk three times. In 16-bit Windows, three consecutive INI file operations would result in only one parse and one write, because the operating system was co-operatively multi-tasked. When you accessed an INI file, it was parsed into memory and cached. The cache was flushed when you finally yielded CPU to another process.
* Many programs open INI files and read them directly. This means that the INI file format is locked and cannot be extended. Even if you wanted to add security to INI files, you can't. What's more, many programs that parsed INI files were buggy, so in practice you couldn't store a string longer than about 70 characters in an INI file or you'd cause some other program to crash.
* INI files are limited to 32KB in size.
* The default location for INI files was the Windows directory! This definitely was bad for Windows NT since only administrators have write permission there.
* INI files contain o -
Re:blame Apple and/or Adobe?
If we speak about Carbon, MS could be one of large companies to blame. Apple got sick of companies like Microsoft still pushing Carbon apps to users completely ignoring Cocoa and they have taken some measures against them on Leopard.
In fact, Microsoft got a surprise when XCode 3 refused to compile (and ship?) MS Office without them fixing the issues at their code first.
http://blogs.msdn.com/macmojo/archive/2007/10/29/there-s-a-new-cat-in-town.aspx
"When I led our transition from CodeWarrior to Xcode back in late 2005, I noted just how picky the tools were. I'm pleased to note that the gcc toolset is even pickier now, and has helped us find and fix a few bugs that Xcode 2.4 missed."
translation: It refused to compile
Apple's philosophy is really different from MS. They say "We are moving fast, if you keep up with us, that is fine. If you don't? Your app icon will bounce and it won't launch".
Adobe Photoshop could be huge, really huge but there is another huge thing which will ship 64bit Leopard version completely moving to Cocoa. Trolltech Qt 4. They had same issue, they heard the Carbon 64bit issue from WWDC. They didn't use it as excuse (like Adobe) and I am sure they are working on 64bit Qt 4 right now. Add Microsoft too. Seriously, a XCode 3 compiling, Cocoa Microsoft Office 08 is a huge thing. Besides jokes, we should congratulate them for not using it as excuse. -
Re:64 bit is no panacea
That's virtual address space, not physical address space.
http://blogs.msdn.com/oldnewthing/archive/2004/08/22/218527.aspx
32 bit non server versions of Windows do have a 4GB physical address space limitation though, so even if your Bios maps Ram hidden by IO devices above 4GB, Windows XP 32 and Vista 32 won't use it. Windows Server will though. -
Re:Since msft was caught bribing SwedenI said at the time that OOXML's fast track process should be terminated after the Sweden incident (even if just for PR purposes, if nothing else). Then OOXML would go to the slow-track. Of course, Microsoft didn't want to use the slow-track process because by the time that process completed years later, IBM would've convinced governments to mandate exclusive use of ODF, and thereby make it illegal to use OOXML (which was the ultimate goal of anti-Microsoft forces). But I thought that if that's the price Microsoft had to pay for an employee's stupidity, then so be it.
That being said, the Sweden incident was much ado about nothing. Allow me to quote from an Arstechnica post by 'adminfoo':
http://episteme.arstechnica.com/eve/forums/a/tpc/f/174096756/m/718005041931?r=313007141931#313007141931 Do you know the full story of Sweden? How one employee sent an offer to two MS partners, which suggested that those partners should join the Swedish NB, and that MS would in some way pay them back for the joining fees - said mail was deemed inappropriate by MS and a retraction was sent within hours. And it was MS themselves who reported the incident to the Swedish NB - had they not done so, it's possible that no one would ever have heard this story. In the end, Sweden's NB abstained because of other issues.
(It is true that my given link is to a Microsoft employee telling the story - but you can find independent sources of the same thing if you look - and for all the scandal, no one has contradicted Matusow's more complete version of the tale.) BTW, IIRC, the fee for joining these committees is pretty small, so that doesn't provide much of a "bribery" incentive to begin with. -
Novell, Microsoft, and Crispin CowanNovell
-
Resolution of spreadsheet date issue"Did Microsoft happen to completely remove the Excel date bug specification from their so-called "standard"? If the answer is not "Yes", then the standard is still shoddy and should be discarded like the rubbish it is."
-------------------
You refer to Excel's "feature" for being compatible with the leap-year bug introduced by Lotus 1-2-3 in the mid-1980's, right?
This is tricky because there are in existence spreadsheet files that actually rely on the leap-year bug in order to work. These spreadsheet files may rely on the bug implicitly or explicitly (e.g. the spreadsheet author added code to the spreadsheet to workaround the bug), so fixing the bug would break these spreadsheets. (Anyone notice the irony that IBM, the owner of Lotus today, doesn't give a damn about helping users of Lotus 1-2-3 transition their files to ODF format and so is willing, and indeed proud, to provide no path to transition Lotus 1-2-3 files that rely on Lotus' leap-year bug to ODF? But I digress.)
This issue has been addressed in ISO OOXML. Brian Jones made numerous blog entries since the September vote on how this issue was resolved:
2007-12-11: Allowing for ISO-8601 Dates
2007-12-21: Dates and the Leap Year Bug
2008-03-15: Discussion of dates and leap-year bug at the BRM
2008-03-25:
http://blogs.msdn.com/brian_jones/archive/2008/03/25/can-i-mention-that-it-s-also-in-odf.aspx Spreadsheet Dates
Folks have been discussing this one for about a year now; it's about the date format used in SpreadsheetML. In the Ecma responses and even in the BRM, we made a number of changes to make everyone happy. Here is where we are now with dates in SpreadsheetML:
* There is a new date datetype for cell values, and the only way to store into that datatype is with ISO 8601.
* For calculations primarily, there is often the need to convert from a date into a serial value or back. For this purpose you need to know the date base, or epoch, and in the ISO version of ODF there are essentially 3 date bases (only one of which is transitional)
* The leap year bug, and issues around dates before 1900 are now only allowed in transitional conformant files, but if the file is strict it cannot use these. [Snipped text that goes on to talk about how ODF allows multiple ways of storing dates, and implementors must similar conversion techniques as OOXML once the ODF 1.1 (the version that allows spreadsheet formulas) is released.] The upshot is that OOXML spreadsheets can only store dates in ISO 8601 format (unlike ODF, which stores dates in multiple formats), and while old "transitional conformant files" may rely on the leap-year bug, such files are not in "strict" compliance with OOXML.
So the leap-year bug is completely removed for new files, but can be used for transitional files. Which is essentially what you guys wanted, that old files may have to deal with legacy crap, but new files should be "clean". I'm sure this isn't enough to satisfy you, but it was enough for those that matter, and even Rob Weir hasn't made much effort to bash this resolution despite the leap-year bug being his main talking point for well over a year now.
This only further demonstrates how most of you are unaware of the improvements that have been made. The (ostensible) technical reasons for rejecting OOXML were addressed. All you have left are the political reasons, and such reasons should not impact ISO. -
Resolution of spreadsheet date issue"Did Microsoft happen to completely remove the Excel date bug specification from their so-called "standard"? If the answer is not "Yes", then the standard is still shoddy and should be discarded like the rubbish it is."
-------------------
You refer to Excel's "feature" for being compatible with the leap-year bug introduced by Lotus 1-2-3 in the mid-1980's, right?
This is tricky because there are in existence spreadsheet files that actually rely on the leap-year bug in order to work. These spreadsheet files may rely on the bug implicitly or explicitly (e.g. the spreadsheet author added code to the spreadsheet to workaround the bug), so fixing the bug would break these spreadsheets. (Anyone notice the irony that IBM, the owner of Lotus today, doesn't give a damn about helping users of Lotus 1-2-3 transition their files to ODF format and so is willing, and indeed proud, to provide no path to transition Lotus 1-2-3 files that rely on Lotus' leap-year bug to ODF? But I digress.)
This issue has been addressed in ISO OOXML. Brian Jones made numerous blog entries since the September vote on how this issue was resolved:
2007-12-11: Allowing for ISO-8601 Dates
2007-12-21: Dates and the Leap Year Bug
2008-03-15: Discussion of dates and leap-year bug at the BRM
2008-03-25:
http://blogs.msdn.com/brian_jones/archive/2008/03/25/can-i-mention-that-it-s-also-in-odf.aspx Spreadsheet Dates
Folks have been discussing this one for about a year now; it's about the date format used in SpreadsheetML. In the Ecma responses and even in the BRM, we made a number of changes to make everyone happy. Here is where we are now with dates in SpreadsheetML:
* There is a new date datetype for cell values, and the only way to store into that datatype is with ISO 8601.
* For calculations primarily, there is often the need to convert from a date into a serial value or back. For this purpose you need to know the date base, or epoch, and in the ISO version of ODF there are essentially 3 date bases (only one of which is transitional)
* The leap year bug, and issues around dates before 1900 are now only allowed in transitional conformant files, but if the file is strict it cannot use these. [Snipped text that goes on to talk about how ODF allows multiple ways of storing dates, and implementors must similar conversion techniques as OOXML once the ODF 1.1 (the version that allows spreadsheet formulas) is released.] The upshot is that OOXML spreadsheets can only store dates in ISO 8601 format (unlike ODF, which stores dates in multiple formats), and while old "transitional conformant files" may rely on the leap-year bug, such files are not in "strict" compliance with OOXML.
So the leap-year bug is completely removed for new files, but can be used for transitional files. Which is essentially what you guys wanted, that old files may have to deal with legacy crap, but new files should be "clean". I'm sure this isn't enough to satisfy you, but it was enough for those that matter, and even Rob Weir hasn't made much effort to bash this resolution despite the leap-year bug being his main talking point for well over a year now.
This only further demonstrates how most of you are unaware of the improvements that have been made. The (ostensible) technical reasons for rejecting OOXML were addressed. All you have left are the political reasons, and such reasons should not impact ISO. -
Resolution of spreadsheet date issue"Did Microsoft happen to completely remove the Excel date bug specification from their so-called "standard"? If the answer is not "Yes", then the standard is still shoddy and should be discarded like the rubbish it is."
-------------------
You refer to Excel's "feature" for being compatible with the leap-year bug introduced by Lotus 1-2-3 in the mid-1980's, right?
This is tricky because there are in existence spreadsheet files that actually rely on the leap-year bug in order to work. These spreadsheet files may rely on the bug implicitly or explicitly (e.g. the spreadsheet author added code to the spreadsheet to workaround the bug), so fixing the bug would break these spreadsheets. (Anyone notice the irony that IBM, the owner of Lotus today, doesn't give a damn about helping users of Lotus 1-2-3 transition their files to ODF format and so is willing, and indeed proud, to provide no path to transition Lotus 1-2-3 files that rely on Lotus' leap-year bug to ODF? But I digress.)
This issue has been addressed in ISO OOXML. Brian Jones made numerous blog entries since the September vote on how this issue was resolved:
2007-12-11: Allowing for ISO-8601 Dates
2007-12-21: Dates and the Leap Year Bug
2008-03-15: Discussion of dates and leap-year bug at the BRM
2008-03-25:
http://blogs.msdn.com/brian_jones/archive/2008/03/25/can-i-mention-that-it-s-also-in-odf.aspx Spreadsheet Dates
Folks have been discussing this one for about a year now; it's about the date format used in SpreadsheetML. In the Ecma responses and even in the BRM, we made a number of changes to make everyone happy. Here is where we are now with dates in SpreadsheetML:
* There is a new date datetype for cell values, and the only way to store into that datatype is with ISO 8601.
* For calculations primarily, there is often the need to convert from a date into a serial value or back. For this purpose you need to know the date base, or epoch, and in the ISO version of ODF there are essentially 3 date bases (only one of which is transitional)
* The leap year bug, and issues around dates before 1900 are now only allowed in transitional conformant files, but if the file is strict it cannot use these. [Snipped text that goes on to talk about how ODF allows multiple ways of storing dates, and implementors must similar conversion techniques as OOXML once the ODF 1.1 (the version that allows spreadsheet formulas) is released.] The upshot is that OOXML spreadsheets can only store dates in ISO 8601 format (unlike ODF, which stores dates in multiple formats), and while old "transitional conformant files" may rely on the leap-year bug, such files are not in "strict" compliance with OOXML.
So the leap-year bug is completely removed for new files, but can be used for transitional files. Which is essentially what you guys wanted, that old files may have to deal with legacy crap, but new files should be "clean". I'm sure this isn't enough to satisfy you, but it was enough for those that matter, and even Rob Weir hasn't made much effort to bash this resolution despite the leap-year bug being his main talking point for well over a year now.
This only further demonstrates how most of you are unaware of the improvements that have been made. The (ostensible) technical reasons for rejecting OOXML were addressed. All you have left are the political reasons, and such reasons should not impact ISO. -
Resolution of spreadsheet date issue"Did Microsoft happen to completely remove the Excel date bug specification from their so-called "standard"? If the answer is not "Yes", then the standard is still shoddy and should be discarded like the rubbish it is."
-------------------
You refer to Excel's "feature" for being compatible with the leap-year bug introduced by Lotus 1-2-3 in the mid-1980's, right?
This is tricky because there are in existence spreadsheet files that actually rely on the leap-year bug in order to work. These spreadsheet files may rely on the bug implicitly or explicitly (e.g. the spreadsheet author added code to the spreadsheet to workaround the bug), so fixing the bug would break these spreadsheets. (Anyone notice the irony that IBM, the owner of Lotus today, doesn't give a damn about helping users of Lotus 1-2-3 transition their files to ODF format and so is willing, and indeed proud, to provide no path to transition Lotus 1-2-3 files that rely on Lotus' leap-year bug to ODF? But I digress.)
This issue has been addressed in ISO OOXML. Brian Jones made numerous blog entries since the September vote on how this issue was resolved:
2007-12-11: Allowing for ISO-8601 Dates
2007-12-21: Dates and the Leap Year Bug
2008-03-15: Discussion of dates and leap-year bug at the BRM
2008-03-25:
http://blogs.msdn.com/brian_jones/archive/2008/03/25/can-i-mention-that-it-s-also-in-odf.aspx Spreadsheet Dates
Folks have been discussing this one for about a year now; it's about the date format used in SpreadsheetML. In the Ecma responses and even in the BRM, we made a number of changes to make everyone happy. Here is where we are now with dates in SpreadsheetML:
* There is a new date datetype for cell values, and the only way to store into that datatype is with ISO 8601.
* For calculations primarily, there is often the need to convert from a date into a serial value or back. For this purpose you need to know the date base, or epoch, and in the ISO version of ODF there are essentially 3 date bases (only one of which is transitional)
* The leap year bug, and issues around dates before 1900 are now only allowed in transitional conformant files, but if the file is strict it cannot use these. [Snipped text that goes on to talk about how ODF allows multiple ways of storing dates, and implementors must similar conversion techniques as OOXML once the ODF 1.1 (the version that allows spreadsheet formulas) is released.] The upshot is that OOXML spreadsheets can only store dates in ISO 8601 format (unlike ODF, which stores dates in multiple formats), and while old "transitional conformant files" may rely on the leap-year bug, such files are not in "strict" compliance with OOXML.
So the leap-year bug is completely removed for new files, but can be used for transitional files. Which is essentially what you guys wanted, that old files may have to deal with legacy crap, but new files should be "clean". I'm sure this isn't enough to satisfy you, but it was enough for those that matter, and even Rob Weir hasn't made much effort to bash this resolution despite the leap-year bug being his main talking point for well over a year now.
This only further demonstrates how most of you are unaware of the improvements that have been made. The (ostensible) technical reasons for rejecting OOXML were addressed. All you have left are the political reasons, and such reasons should not impact ISO. -
Re:Abandon All HopeWouldn't it be technologically superior to require MS Word to emulate "truncateFontHeightsLikeWP6" using standard formatting directives, rather than forcing every other implementer to code for compatibility with some file format that isn't even part of the spec? It's suppressTopSpacingWP. Look at the part of the spec quoted here -
http://blogs.msdn.com/brian_jones/archive/2008/01/18/suppresstopspacingwp-compat-settings-1.aspx
This is what happens when the user selects "Suppress extra line spacing like WordPerfect 5.x" in Tools->Options->Compatibility. If suppressTopSpacingWP didn't exist, that UI element could not work. If you don't want to implement it in your competing office suite, no one is forcing you. If you do want to support documents saved when it was checked, the effect it has on basline to baseline distance is documented thanks to the ISO process where people complained until it was documented. That was the quid pro quo for them voting for it as a standard rather than against. -
Re:Abandon All Hope"Cue persistent formal requests to MS for specification details regarding "auto space like Word 95" et al. It's obviously the first step on the road to litigation/anti-trust cases."
--------------
This shows your ignorance (and that of the general slashdot population). The "auto space like Word 95" issue has been addressed in the latest spec (the spec that's beeen approved). That "auto space like Word 95" behavior, and the others like it, are now marked as "deprecated" (i.e. should not use for new documents) AND are fully spec'ed. Compatibility Settings - AutoSpaceLikeWord95
There has also been a lot of interest in the Compatibility Settings that include the famous "AutoSpaceLikeWord95" or "truncateFontHeightsLikeWP6". Ecma worked to provide in this batch the full information necessary to implement all compatibility settings without any dependency on any product. This documentation is provided for the completeness of the spec, but these features should not be used when creating new documents. I'll discuss the compatibility settings in more detail in my next post And here are further details.
See, this is the problem: So many of you that are railing against OOXML and against the ISO process are completely ignorant of the facts on the ground. The technical issues that you claimed to be concerned with have been addressed. So there's no technical reason to reject OOXML (there may be *political* reasons, but such reasons should have no bearing on ISO).
For example, the Czech Republic voted NO in September, but switched to YES. Why? Because nearly every one of their issues have been addressed now.
http://xmlguru.cz/2008/01/ecma-response-to-czech-ooxml-comments
Do you really expect the Czech Republic to continue to oppose OOXML when nearly all of its objections to the original spec have been fixed? Why would they do that? The problems were fixed, so they switched to YES, and this was the case with many countries (those without a political agenda).
It's like you guys are impervious to the fact that the OOXML spec has been quite improved (and that you're ranting about some old issue like "auto space like Word 95", an issue that has been resolved, *proves* it). Maybe, just maybe, if you took some time to learn the facts, learn how the spec has been changed since Sept, you'd not be so against OOXML (unless, as I suspect, your opposition is due to *political* reasons, under the mere guise of technical reasons). -
Re:Abandon All Hope"Cue persistent formal requests to MS for specification details regarding "auto space like Word 95" et al. It's obviously the first step on the road to litigation/anti-trust cases."
--------------
This shows your ignorance (and that of the general slashdot population). The "auto space like Word 95" issue has been addressed in the latest spec (the spec that's beeen approved). That "auto space like Word 95" behavior, and the others like it, are now marked as "deprecated" (i.e. should not use for new documents) AND are fully spec'ed. Compatibility Settings - AutoSpaceLikeWord95
There has also been a lot of interest in the Compatibility Settings that include the famous "AutoSpaceLikeWord95" or "truncateFontHeightsLikeWP6". Ecma worked to provide in this batch the full information necessary to implement all compatibility settings without any dependency on any product. This documentation is provided for the completeness of the spec, but these features should not be used when creating new documents. I'll discuss the compatibility settings in more detail in my next post And here are further details.
See, this is the problem: So many of you that are railing against OOXML and against the ISO process are completely ignorant of the facts on the ground. The technical issues that you claimed to be concerned with have been addressed. So there's no technical reason to reject OOXML (there may be *political* reasons, but such reasons should have no bearing on ISO).
For example, the Czech Republic voted NO in September, but switched to YES. Why? Because nearly every one of their issues have been addressed now.
http://xmlguru.cz/2008/01/ecma-response-to-czech-ooxml-comments
Do you really expect the Czech Republic to continue to oppose OOXML when nearly all of its objections to the original spec have been fixed? Why would they do that? The problems were fixed, so they switched to YES, and this was the case with many countries (those without a political agenda).
It's like you guys are impervious to the fact that the OOXML spec has been quite improved (and that you're ranting about some old issue like "auto space like Word 95", an issue that has been resolved, *proves* it). Maybe, just maybe, if you took some time to learn the facts, learn how the spec has been changed since Sept, you'd not be so against OOXML (unless, as I suspect, your opposition is due to *political* reasons, under the mere guise of technical reasons). -
Re:Nice Sentiment
http://blogs.msdn.com/brian_jones/archive/2006/05/26/607630.aspx
http://blogs.msdn.com/brian_jones/archive/2006/06/01/612952.aspx
It's really not hard to find more, one of the side effects of all the negative attention OOXML has had is that ODF is getting a lot of scrutiny and a lot of issues are being found with it as well. For instance, performance wasn't a goal when designing ODF - which isn't necessarily a bad thing, but Microsoft have been doing this for a long time and realise the importance of performance. -
Re:Nice Sentiment
http://blogs.msdn.com/brian_jones/archive/2006/05/26/607630.aspx
http://blogs.msdn.com/brian_jones/archive/2006/06/01/612952.aspx
It's really not hard to find more, one of the side effects of all the negative attention OOXML has had is that ODF is getting a lot of scrutiny and a lot of issues are being found with it as well. For instance, performance wasn't a goal when designing ODF - which isn't necessarily a bad thing, but Microsoft have been doing this for a long time and realise the importance of performance. -
Re:What's with the Fisher-Price trend?
Actually, almost all user interface actions in Windows can be controlled with keys. Back in the Win95 days you could see this easily - hotkeys were underlined in UI items. Now the quest for style of substance has caused them to be hidden by default. But hold down the Alt key and most Windows applications will be full of keyboard accelerators. E.g. in Opera Alt F opens the file menu. Alt+F, S will save for example. Most applications have Ctrl key combinations like Ctrl+S to do the same thing. Accelerators are part of the OS, but developers need to add & characters to their
-
Lots of online stuff too
I stumbled across this guide to deconstructing a C++ exception.
http://blogs.msdn.com/slavao/archive/2005/01/30/363428.aspx
Lots of this is applicable to any platform, not just Windows. -
Re:Not just C++
Teaching lisp, prolog, simula etc at university is an excellent idea. Make them think.
As for
the thing is, if you tell a less-capable programmer that he doesn't have to worry about memory, he'll think christmas has come early and he will stop worrying about memory... as a result his code will become poorer, resource consumption will increase dramatically, performance will tank and scalability will be non-existent. And his code will become even less maintainable.
Now make him program in a language where he is punished for cocking things up, he will *have* to become a better programmer or nothing he does will get released.
Now, that's an ideal, in the real world poor code will still get shipped to customers regardless of how it was developed; but the code written in an 'easy' langauge will still contain bugs.
eg. I saw a recent question on our internal tech mailing list - someone asked why his code was failing to connect to the DB, he was told "oh you have to put gc.collect() in any loop tht connects to the DB to fix that". -
Re:I completely agree
I agree too, to quote TFA: "Conversely, there is now a generation who is firmly convinced that a program is only well-designed if just about everything is part of a class hierarchy and just about every decision is delayed to run-time."
I'm not sure if the problem is bad education or the lazy coders who expect everything to be easy (ie done for them) so they don't have to really think about what they're doing.
Even MS's clever chaps have this problem - "lets have C# and GC so no-one need think about memeory ever again" they cried. Then they realised that objects are more than just memory so you do have to worry about destruction of the non-memory resources held by an object (eg file handle, etc). Then they realised they were getting problems writing code that interacted with the OS, so they introduced reference counting objects that they could put in their "deterministic" finalisation objects that they could put in their Garbage-collected objects. -
Re:Popcorn anyone?
Well how about instead of making silly statements like this, you go read the documentation on IE7 protected mode. It quite thoroughly answers your question.
I'll even be nice and give you some of the information.
There are special cache locations in the registry and user profile called 'Low' that are the only places readable/writeable by IE7 in protected mode.
I did mis-speak in one sense in my post -
Re:Something is FishyI'm only pointing out that it is irrelevant whether the vulnerability was in Flash or in Windows, or even in Firefox, since the problem is the same: Windows is still carrying the baggage of a single-user system and as long as that is the case it will be easier to exploit. UAC does raise the barrier, but addresses a problem that only exists on Windows, since that OS still does not properly compartmentalize users the way other OSs do.
What the hell? Do you only read highly moderated Slashdot comments for all your information on Windows or what? One exploit in Firefox or Flash on Linux(default config on all major distros) can completely and silently wipe away all your user files or ftp them to Nigeria. All your smug talk about proper compartmentalization in "other OSes" won't help shit to stop that. Can you tell us what exactly on Linux would prevent the same hole in flash(or in Firefox) from shitting all over your user directory?
UAC does raise the barrier, but addresses a problem that only exists on Windows, since that OS still does not properly compartmentalize users the way other OSs do.UAC is basically sudo and like the root password prompts that come up under GUI in Linux, except that MS didn't think that it would make sense to prompt a user already designated as a admin to enter the password because the vast majority of their users run in a single user environment. If the user is not an admin, then the admin password is prompted for. Can your provide some references for how windows not properly com
Contrast that to IE7 on Vista. Read this . It's in part a implemtation of the Biba security model . So a similar vulnerability in IE7 or any of its plugins(including Flash) will only be able work in sandbox that prevents access to anything but low risk files like temporary internet files.
From the linked article: Internet-facing applications such as browsers are inherently at a higher security risk than other applications because they can download untrustworthy content from unknown sources. IE7s Protected Mode leverage's Windows Vistas UAC, MIC and UIPI features to boost browser security. In IE7s Protected Modewhich is the default in other than the Trusted security zonethe IE process runs with Low rights, even if the logged-in user is an administrator. Since add-ins to IE such as ActiveX controls and toolbars run within the IE process, those add-ins run Low as well. The idea behind Protected Mode IE is that even if an attacker somehow defeated every defense mechanism and gained control of the IE process and got it to run some arbitrary code, that code would be severely limited in what it could do. Almost all of the file system and registry would be off-limits to it for writing, reducing the ability of an exploit to modify the system or harm user files. The code wouldn't have enough privileges to install software, put files in the user's Startup folder, hijack browser settings, or other nastiness.So in order for the exploit on Flash to work on Vista SP1, it must have been run on Firefox/Opera/Safari/ OR it must have been run on IE7 and broken through the sandbox(quite possible, but the news shouldn't be about not only a exploit in Flash, but another one in Windows as well). THAT is the point of your parent post. And no, this is not an assumption. It's a fact even if you bury your head in sand.
My own logic is sound. But I suggest that next time you feel like discussing such things, you rely on facts and leave assumptions at the door. I don't know what is worse, your lack of basic knowledge of what you're talking about or your smug self-superiority and overconfidence in the OS that you chose and your 'M$ sucks' zealotry. -
Re:Something is Fishy
Read the exchanges on the iebloc here: http://blogs.msdn.com/ie/archive/2006/11/17/flash-player-9-update.aspx. It also contains links to documentation.
-
Something is Fishy
If the person on the Vista laptop was running IE 7 with the default configuration (protected mode / UAC on), this should not have happened.
Flash, like all other plugins, run within the security context of the low-rights user used by protected mode. Even if the flash plugin had an obvious buffer overflow or other exploit, it would only be able to access the data accessible by that low rights user, NOT the user running IE. That's the point of protected mode.
For a flash plugin to allow for a hacker to access personal files of the user it would not only have to have a buffer overflow (or some other exploit) in flash itself, but also take advantage of a privledge elevation exploit in Windows simultaneously.
I didn't see them specify in the article what browser than were using. Since they said it was an issue with flash, and not Windows, they couldn't have been using IE. My guess is that it was Firefox, since they said they loaded "popular" 3rd party apps.
Futhermore, the file in question must have been accessible to the user running Firefox (or whatever non-IE browser) since that would also require a privledge elevation in Windows.
So I'm not really sure how you can blame this on Vista or even Microsoft. If they had been using IE, it wouldn't have happened, regardless of the flaws in Flash. This says absolutely nothing about Vista security. The exact same thing would happen on every other OS. If you have an app with an exploit, and that app is running as User A, the hacker using that exploit has the same rights as User A.
I suppose one could argue that various defensive techniques like ASLR should have stopped this, but without knowing the details, that's impossible to say. A buffer overflow can just as easily be used to call APIs exposed by the exploited application as it can to call OS APIs, and since ASLR only applies to Windows APIs (indeed, many of these techniques only apply at the OS level), this wouldn't be a fair characterization either.
Indeed, I find it strange that they didn't mention mitigating factors. I realize they're trying to be responsible as far as reporting, but telling people that users running IE on Vista aren't affected isn't exactly giving anything away... aside from the fact that Vista did its job as best it could. -
Something is Fishy
If the person on the Vista laptop was running IE 7 with the default configuration (protected mode / UAC on), this should not have happened.
Flash, like all other plugins, run within the security context of the low-rights user used by protected mode. Even if the flash plugin had an obvious buffer overflow or other exploit, it would only be able to access the data accessible by that low rights user, NOT the user running IE. That's the point of protected mode.
For a flash plugin to allow for a hacker to access personal files of the user it would not only have to have a buffer overflow (or some other exploit) in flash itself, but also take advantage of a privledge elevation exploit in Windows simultaneously.
I didn't see them specify in the article what browser than were using. Since they said it was an issue with flash, and not Windows, they couldn't have been using IE. My guess is that it was Firefox, since they said they loaded "popular" 3rd party apps.
Futhermore, the file in question must have been accessible to the user running Firefox (or whatever non-IE browser) since that would also require a privledge elevation in Windows.
So I'm not really sure how you can blame this on Vista or even Microsoft. If they had been using IE, it wouldn't have happened, regardless of the flaws in Flash. This says absolutely nothing about Vista security. The exact same thing would happen on every other OS. If you have an app with an exploit, and that app is running as User A, the hacker using that exploit has the same rights as User A.
I suppose one could argue that various defensive techniques like ASLR should have stopped this, but without knowing the details, that's impossible to say. A buffer overflow can just as easily be used to call APIs exposed by the exploited application as it can to call OS APIs, and since ASLR only applies to Windows APIs (indeed, many of these techniques only apply at the OS level), this wouldn't be a fair characterization either.
Indeed, I find it strange that they didn't mention mitigating factors. I realize they're trying to be responsible as far as reporting, but telling people that users running IE on Vista aren't affected isn't exactly giving anything away... aside from the fact that Vista did its job as best it could. -
Re:Certified
And what exactly do you think WHQL certification means beyond that the software passed the WHQL tests in a lab? Defrauding the WHQL driver certification process. Perhaps you think that all possible combinations of code paths and system states should be verified for correctness mathematically proving that the driver won't bugcheck your machine? Even if the card is overclocked, poorly cooled, and using a shoddy power supply? Are you sure you're not just grasping at any reason to hate Microsoft? There may be valid reasons, but the crappiness of NVIDIA's drivers isn't one of them. Shouldn't your outrage be directed at NVIDIA?
-
Re:linky, pleasey
Here is your linkey http://blogs.msdn.com/ie/archive/2006/02/09/528963.aspx
Quote from the linkey
In IE7's Protected Mode--which is the default in other than the Trusted security zone--the IE process runs with Low rights, even if the logged-in user is an administrator. Since add-ins to IE such as ActiveX controls and toolbars run within the IE process, those add-ins run Low as well. The idea behind Protected Mode IE is that even if an attacker somehow defeated every defense mechanism and gained control of the IE process and got it to run some arbitrary code, that code would be severely limited in what it could do. Almost all of the file system and registry would be off-limits to it for writing, reducing the ability of an exploit to modify the system or harm user files. The code wouldn't have enough privileges to install software, put files in the user's Startup folder, hijack browser settings, or other nastiness.
In Protected Mode IE writes/reads special Low versions of the cache, TEMP folder, Cookies and History:
Cache: %userprofile%\AppData\Local\Microsoft\Windows\Temporary Internet Files\Low
Temp: %userprofile%\AppData\Local\Temp\Low
Cookies: %userprofile%\AppData\Roaming\Microsoft\Windows\Cookies\Low
History: %userprofile%\AppData\Local\Microsoft\Windows\History\Low -
Yes, it's called IE 7 on Vista (seriously)
I know, I know... this is Slashdot, I shouldn't bother. But IE 7 on Vista (running in Protected Mode) is pretty damn secure.
While there have been exploits for IE 7, not a single one of them could successfully bypass Protected Mode. I'd say that's a pretty damn good track record for a browser that has been out for about a year and a half and has undoubtedly been targeted by many, many bad guys. (And good guys, for that matter.) -
Re:The Next Milestone
And Acid2, for all its emphasis on CSS, hasn't fixed CSS -- it's still wildly different everywhere, even if you only consider Acid2-passing browsers.
That hasn't been my experience.
my HTML pages don't look or act quite the same in any of them.
That in itself isn't necessarily a bug. Examples? And make your mind up — "wildly different everywhere" and "don't look or act quite the same" are two very different things.
That's neat, but how hard is it really to write a more authoritative test suite?
I'm not sure what you mean by authoritative, but there have been CSS test suites available at the W3C for years and Microsoft have just submitted over 700 more tests for inclusion.
-
Re:Well...
Not necessarily. It still depends upon your hardware, regardless of the operating system that you use. This site has an explanation of the 4GB to 3GB problem.
-
Re:SatisfyingGiven that it has marketshare that is a fraction of OS X, I don't think Microsoft is exactly reeling at the 'rise of ubuntu' right now. Its a blip on the radar. I'm not that sure about that; linux's market share right now is low, but I think there are definitely people at Microsoft worrying that it would get bigger; and the big difference with OS X is that it's not led by the same logic: people who've tried linux will stay for the price, and the complete absence of lock-in.
The X0 and eeePC threats are:
1) People might hear about linux in mainstream medias, and not as some computer-freak oriented gimmick, but as something targeted at kids (and in the case of the eeePC, sentences like "simple to use tabbed base interface, integrating skype and firefox" were everywhere). They might also notice that it doesn't cost anything.
2) Poorer countries have entered the market for computers; we're speaking many times the current market. If they get millions of linux boxes right now, it might become the de facto standard there.
To address this, Microsoft has already:
1) Tolerated widespread piracy of windows in China, and admited to do so:
http://labnol.blogspot.com/2007/07/we-love-microsoft-software-piracy-in.html
2) Made IE7 work even if wga doesn't pass, (because you want to punish pirates, but not to incite them try firefox):
http://blogs.msdn.com/ie/archive/2007/10/04/internet-explorer-7-update.aspx
3) Tweaked XP (IIRC) to make it work on the eeePC. I saw an eeePC on display the other day, and people were gathering around it; I thought "hey, a linux box is getting some hype, great!", but you could see the XP wallpaper on it.
4) Did everything they could to reduce the amount of linux machines bought by Brasil for schools and such. No. They really simply didn't care. You can get 2GB of desktop ram for ~$45 now. They didn't care that it takes like 12GB to install either, for the same reason. Not if the eeePC is the start of a "race to the bottom". And with people realising that web surfing and text editing only takes 300$ of hardware, 45$ could well be too much, even in rich country. Plus you've got handheld devices: I don't think there will be a shortage of devices with less than 512m of RAM in the near future (and don't forget wiis, modems, smart tvs...). and by planning to release it one year early.
I think that's more marketing than anything else. I don't remeber the details, but it seems to me that Vista was many time pushed to a later release date, not the contrary; it seems to me that they really spend a lot of energy to get it early this time. But I agree that it's not done yet.
Not that I disagree with everything you said (especially the part about virtualisation), but I think you focused too much on US companies, as opposed to the now-worldwide market for OSs. -
Re:The answer...At the bottom, TFA links to this IEBlog which states:
To maintain compatibility and be secure by default we didn't want to invoke fallback either, as original web authors might not have intended this behavior.
Dear MS:
A fallback, be definition, means that if you can't render the original, fall back to this content. This is exactly what the web author would have wanted. Thank you.
-
WTF? why is this on Slashdot?
http://blogs.msdn.com/ie/archive/2008/03/05/why-isn-t-ie8-passing-acid2.aspx This has long since been addressed already.
-
Known Cross-domain security issue
The reason you're seeing the result is due to an "overly secure" default for beta 1 when it comes to cross-domain embedded objects.
Here's the explanation:
http://blogs.msdn.com/ie/archive/2008/03/05/why-isn-t-ie8-passing-acid2.aspx
Google is your friend next time... -
The answer...
As TFA mentions (at the very end!) this is explained here.
Summary: cross-site security means that if you move the test off the original domain, the test changes. In fact IE8 does the wrong (nonstandard) thing in these cases, but according to them it's more secure (it fails earlier). They're considering making it more standards compliant once they're convinced it's secure enough.
-
Re:MicrostudiosAnd nobody else can play them unless they also pay $495 over the 5-year life of a console For less than the price of two name-brand games a year, they can play every XNA game (plus develop their own, using free tools). That's not such a bad deal. And... or unless you get a Big Company to publish your game. ... later this year, you'll be able to self-publish them on Xbox Live for anyone to download.
-
Re:WTF does Microsoft know about virtualization?
Stop letting off hot air on the dumbass article. See installing fedora core 8 on hyper-v . Even Ubuntu server is being used by people on HyperV. SUSE is supported in the sense of calling up MS's support desk and talking to them about it. But Linux distributions work just fine. This is just MS's way of telling people that they're on their own if they try other distributions(this is usually true for Linux servers anyway).
Misinformed blogger makes a flamebait article that reads like ex-lover's childish rant complete with doomsday threats and with a inflammatory headline, the 'editor' doesn't do any editorial work and the hundreds of misguided comments below will just bash on MS and earn insightful, informative and interesting mod points. Also, this will be repeated in the comments in other articles as the gospel truth because most people don't even RTFA, forget about actually seeing if there is a grain of truth in it. In other words, just another day on Slashdot.
If you really want to know about Hyper V, go here .
-
Re:How about ...
Interestingly, this is Raymond Chen's argument against open source: that developers would then dig into the Windows source code looking for undocumented side-effects, data structures and other crap, use them on production programs, then Microsoft would never, ever be able to change or fix them in the future. I don't know how (or even if) the Linux community solves this problem, but it's a pretty sensible concern from my point of view. It's better for programmers to follow the prescribed methods, which leaves room for the OS maker to improve whatever they want internally.
http://blogs.msdn.com/oldnewthing/archive/2003/12/23/45481.aspx#45759 (There's a better link where he explains it in more detail, but I can't seem to find it right now.)