Slashdot Mirror

What about XBox 360?

What? For every .NET API there are 5+ APIs for Java.

Depends on the area. For example, Java has many more web frameworks or ORMs. But then some tricks are simply beyond its reach, because it doesn't have the language features that are needed to complete the puzzle, whereas .NET (C#/VB) does - e.g. LINQ (specifically its expression trees, though using it for general-purpose monadic computations is also a neat hack), or first-class functions and concise lambdas.

they won't take the year needed to create the custom software required to make a touch based device useful

Except that with Windows 7, Microsoft has already released a very usable multitouch OS. I doesn't have the novelty factor of the iPhone OS, but it's got all the little gestures and whatnot. The spacing between buttons actually changes when you're using touch vs. when your using a mouse or a stylus. You can take a look at the touch support here.

I've been using a tablet pc from motion computing for almost half a year now and it's great! The handwriting recognition is impressive, and once it's been trained for a while, is amazing. It can read my writing - I can't even do that. Admittedly its three times the price of an iPad, but it's actually usable. If I were to buy an iPad, it would just sit around being unused. I can read fine sunlight, so I can use it anywhere. It's a full computer, so I can install OneNote, or whatever I feel like. Oh, and I can write my own software for it.

Here is another similar story from the Old New Thing blog later: http://blogs.msdn.com/oldnewthing/archive/2009/11/23/9927055.aspx

Yes, the SVG support in the Platform Preview is definitely a work in progress; it really should be viewed as an early alpha in overall completeness and quality. However, MS has apparently committed to a full and proper SVG implementation in IE9. Some links worth checking out:

Platform Preview gives Web developers first taste of IE9 - Scroll down to SVG heading for a nice summary

SVG in IE9 Roadmap - Official IE blog post on SVG

here is an interesting video with leslie lamport ( http://en.wikipedia.org/wiki/Leslie_Lamport ) : http://channel9.msdn.com/shows/Going+Deep/E2E-Erik-Meijer-and-Leslie-Lamport-Mathematical-Reasoning-and-Distributed-Systems/ "When you understand something, then you can find the math to express that understanding. The math doesn't provide the understanding." “The mathematics of computing; things like sets and functions and logic, are to computing what real numbers are to physics.”

Your brain is stuck in 5 years ago:

http://blogs.msdn.com/ie/

(Contact information is plastered all over that page)

The Microsoft Windows equivalent of Grand Central Dispatch is called User-Mode Scheduling, and is included with Windows 7 and Windows Server 2008 R2.

http://msdn.microsoft.com/en-us/library/dd627187(VS.85).aspx

Microsoft has also released application libraries on top of UMS to make it easier to use in certain languages. C++, for example, has the Concurrency Runtime. More on that here:

http://msdn.microsoft.com/en-us/library/dd504870(VS.100).aspx

GDC and UMS both let an application developer accomplish pretty much the same thing: move all into a single process with enough pre-assigned threads to cover all the cores on a system, and then work is queued up and performed on those threads. The benefit of here is that GCD and UMS applications don't have to context-switch into and out of the kernel a bazillion times in order to do a set of parallelizable tasks.

GDR and UMS+CCR both whittle down the developer's code-writing commitment to a few lines. It's pretty amazing stuff.

BUT....

Neither of these technologies really addresses the underlying system-wide problem: adding more CPU cores to a system doesn't increase performance on a linear scale like increasing the speed of the CPU. Every time you add a core, more and more time gets spent doing resource management instead of actual work. OS kernels invariably have locks on important resources (memory tables, for example), and while these things don't matter at all on a 2 or 4 core system, they're going to be a huge bottleneck on a 200-core system. No general-purpose operating system on the market today... not Windows, not OS X, not even Linux... can provide a liner or near-linear performance improvement as the number of cores increase beyond 16 or so. Not as long as there is any kind of shared resource between those cores.

By the way.... Dave Probert, who is the Microsoft engineer the Slashdot article is discussing, explained UMS in this Channel 9 video over a year ago:

http://channel9.msdn.com/shows/Going+Deep/Dave-Probert-Inside-Windows-7-User-Mode-Scheduler-UMS/

One Windows 7 feature/API/interface/whatever Microsoft has been pushing these days is Direct2D and DirectWrite. (That's two, I know; just play along.) Basically a way to draw vector shapes and smooth text and shit with a DirectX-based COM interface. The text is a bit different from the usual ClearType, because it smooths vertically as well as horizontally.

Microsoft has said they'll use the "Direct"s in IE9* and that they've joined the SVG working group, and have already done vector stuff with VML, so it's clear they want to use the Directs to implement (some subset of) SVG. They got Acid2 working in IE8, so they may as well punch in the SVG stuff used in Acid3; and if they can make a nice, fast GPU-land engine that renders the hypertext and the shapes, IE9 could actually be nice. IE8 can still be slow with pages, such as Wikipedia's often-long list of featured article candidates (though I've tried it now and it doesn't seem as horrible as I remember...hmm), so the GPU stuff may help.

*One of the comments there reads, "instead of focusing on things like: Direct2D and DirectWrite, please focus on better STANDARDS SUPPORT!" I think, and hope, that bort is missing the point.

One Windows 7 feature/API/interface/whatever Microsoft has been pushing these days is Direct2D and DirectWrite. (That's two, I know; just play along.) Basically a way to draw vector shapes and smooth text and shit with a DirectX-based COM interface. The text is a bit different from the usual ClearType, because it smooths vertically as well as horizontally.

Microsoft has said they'll use the "Direct"s in IE9* and that they've joined the SVG working group, and have already done vector stuff with VML, so it's clear they want to use the Directs to implement (some subset of) SVG. They got Acid2 working in IE8, so they may as well punch in the SVG stuff used in Acid3; and if they can make a nice, fast GPU-land engine that renders the hypertext and the shapes, IE9 could actually be nice. IE8 can still be slow with pages, such as Wikipedia's often-long list of featured article candidates (though I've tried it now and it doesn't seem as horrible as I remember...hmm), so the GPU stuff may help.

*One of the comments there reads, "instead of focusing on things like: Direct2D and DirectWrite, please focus on better STANDARDS SUPPORT!" I think, and hope, that bort is missing the point.

I got the udpate from here:
For 32-bit host operating systems: http://www.microsoft.com/downloads/details.aspx?FamilyID=837f12aa-1d37-464e-ae59-20c9ecbebaf6
For 64-bit host operating systems: http://www.microsoft.com/downloads/details.aspx?FamilyID=e70dd043-e262-43c0-a002-446567f1e2b4

(Via: http://blogs.msdn.com/virtual_pc_guy/archive/2010/03/18/windows-virtual-pc-no-hardware-virtualization-update-now-available-for-download.aspx)

Explanation of this decision from Virtual PC blog:

Why is Microsoft making this change to Virtual PC now?

Because of you :-) We have heard loud and clear from customers that they need to be able to run Windows Virtual PC and Windows XP Mode on systems that do not have hardware virtualization support. So we are going to enable this.

Why did Microsoft release Windows Virtual PC without this in the first place?

There are two main reasons here.

The first is that we believe that customers will get the best virtualization experience on computers with hardware virtualization support. This has not changed – and even though we are releasing this update I would strongly encourage anyone who is looking at buying a new computer, and intends to use virtualization, to make sure that they get a system that is capable of supporting hardware virtualization.

The second is that we had hoped that by the time Windows Virtual PC released – hardware virtualization support would be prevalent enough that this would not be an issue. We were wrong on that. Bummer.

Meaning Microsoft controls the kinds of video IE can stream?

This is a big opportunity for Microsoft to force the Internet media standards AND generate some meaningful license fees. Those fees would be paid to Microsoft to enable streaming your hot-new-VC-backed media format. Microsoft would never have to deal with those pesky media streaming competitors they used to call partners.

If I made decisions at Microsoft, that's how I'd do it.

IE9 is supporting "MP4 h.264 video, MP3 or AAC audio - just like Safari, Chrome." Not Theora, of course, but H.264, not some Microsoft-only thing.

Please go to http://blogs.msdn.com/ie/contact.aspx and ask Microsoft to add support for Ogg Theora and Ogg Vorbis. They could add it to the browser, or add support for it to the OS and then have the browser support it. They can support both H.264 and Ogg if they want to. For example, there are many sites like Wikipedia which *ONLY* permit Ogg Theora and Ogg Vorbis for multimedia; without built-in support, IE users have trouble hearing/viewing the content.

and that serve absolutely no other purpose

Or maybe you're too stupid to think of a purpose? Heh, another data point of the fantastic stupidity of anti-ms trolls.

Seriously, tell me *that* is just a bug!

Learn to use google. This has been explained over 5 years ago.

http://blogs.msdn.com/larryosterman/archive/2004/08/12/213681.aspx

Yea, I still remember discussing the "The admin is an idiot" articles:
http://blogs.msdn.com/oldnewthing/archive/2007/05/08/2470753.aspx
http://blogs.msdn.com/larryosterman/archive/2007/07/06/is-there-a-difference-between-an-administrator-and-a-person-with-an-admin-account.aspx

Yea, I still remember discussing the "The admin is an idiot" articles:
http://blogs.msdn.com/oldnewthing/archive/2007/05/08/2470753.aspx
http://blogs.msdn.com/larryosterman/archive/2007/07/06/is-there-a-difference-between-an-administrator-and-a-person-with-an-admin-account.aspx

The XBox is not a fork of Windows at all.

15 seconds of research would have saved you from looking stupid.

From the XBox Engineering Blog:

"One of the first questions I get when someone hears I work on Xbox is "So, what operating system do you guys use? Windows 2000, right?" I am honestly not sure where the Win2K misperception comes from, but Xbox runs a custom operating system built from the ground up. While our operating system exports many of the same APIs found in Win32 (e.g. CreateThread or WaitForSingleObject), not everything is there. For instance, there is no use for CreateWindow on Xbox - all graphics are done through (our own flavor of) Direct3D."

Why do they need to protect me from maintaining my app? If I use an API and they do something that breaks it, it's my responsibility to fix it or they pull the app.

If it's an officially documented API, that is not the case, at least not with Mac OS X (and, as far as I know, with other commercial UN*Xes and Windows). People generally get peeved if updating the OS breaks an app, and the first organization to which they complain is likely to be the OS vendor, so the OS vendor makes at least some effort not to break APIs. I think Raymond Chen has talked about this at Microsoft, and it's also an issue at Apple (try doing nm -p /usr/lib/libSystem.dylib | egrep '\$' on OS X - at least in newer versions, you'll find multiple versions of some APIs, so that the API can be changed without breaking binary compatibility with older apps).

Does the iPhone OS SDK say otherwise? Does it explicitly say that, if any app works on version N and fails to work on version N+1, it's ipso facto the app developer's fault?

Okay, I've googled around, and here a post with comments that talks about it (on MSDN blogs). To sum it up:

1. Start button in Windows 95/98/NT4 did not conform to Fitt's Law.
2. Windows 2000 fixed that.
3. Late Vista betas broke that.
4. Vista release fixed that again.

I agree to the extent that compatibility is an important selling point and it also limits their ability to change their OS.

I'm not so willing to concede that the registry is an example of a design flaw. You have to consider the design within its context. For an explanation of why the registry was created and a discussion for and against it see http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx

If you restrict yourself to a subset of a language, maybe.

Otherwise, C# users have to deal with:

- user-defined value types
- first-class functions
- type inference (did you ever read the spec on how it works for arguments of generic methods when lambdas are involved?..)
- unsigned integral types (and mixed arithmetic issues that arise)
- native pointer types and pointer arithmetic
- operator overloading
- pass-by-reference

just to name a few.

This isn't to say it's a bad thing. All of the above give you more power. Furthermore, one could say that many of those features "just work" in a sense that programmer doesn't typically need to understand how type inference works, for example. But then sometimes they do not, and relying on magic without understanding how it works can land you straight into "here be dragons" land.

All in all, I'd say that it's pretty clear that Java is a simpler language than C# - a cursory glance at language specs of each is enough to conclude that. Whether that simplicity helps ease of use, or hinders it, is a different question.

If you restrict yourself to a subset of a language, maybe.

Otherwise, C# users have to deal with:

- user-defined value types
- first-class functions
- type inference (did you ever read the spec on how it works for arguments of generic methods when lambdas are involved?..)
- unsigned integral types (and mixed arithmetic issues that arise)
- native pointer types and pointer arithmetic
- operator overloading
- pass-by-reference

just to name a few.

This isn't to say it's a bad thing. All of the above give you more power. Furthermore, one could say that many of those features "just work" in a sense that programmer doesn't typically need to understand how type inference works, for example. But then sometimes they do not, and relying on magic without understanding how it works can land you straight into "here be dragons" land.

All in all, I'd say that it's pretty clear that Java is a simpler language than C# - a cursory glance at language specs of each is enough to conclude that. Whether that simplicity helps ease of use, or hinders it, is a different question.

BTW, the taskbar is not the "system tray." To the best of my knowledge there is no "system tray."

For ancient history, please refer to http://blogs.msdn.com/oldnewthing/archive/2003/09/10/54831.aspx

Not only did Microsoft announce this on their Outlook 2010 blog back on Jan 22, but they announced the patch for it on Feb 11.

And it's beta software. We kinda expect it to make mistakes. Unlike some companies that keep their products in beta for a decade.

I've been using Office 2010 for a few months now and absolutely love it. It's not very different from 2007. Just refined, like Windows 7 is to Vista. It has a few new features in each application that users will enjoy, especially in Sharepoint environments.

One very cool feature in Outlook is the "People Pane" which appears optionally next to the message you're reading. Expand it and it will show you all of your prior appointments, emails, IMs, attachments, and more that are connected to that person. So when Fred sends you an email and says "what did you think about that other email I sent you?" it's a piece of cake to find it.

But oh noes! A beta has a bug! There must be nothing else to bash Microsoft for today.

http://channel9.msdn.com/posts/LauraFoy/First-Look-Windows-Phone-7-Series-Hands-on-Demo/

(Silverlight warning, at least it does work on Chrome on Mac)

I just saw a video on Channel 9 showing that the Hard Rock Cafe is using Microsoft Surface and other touchscreen devices in a few of their restaurants. Considering the device was only release about 2 years ago and has such a large price tag I am still impressed with what they have done. Check it out:

http://channel9.msdn.com/posts/LarryLarsen/The-Tech-Behind-The-Hard-Rock-Cafe/Default.aspx

Wikipedia mentions AT&T, Harrah’s, Disneyland, Sheraton Hotels and MSNBC as users of the Microsoft Surface too. I have yet to see one, but it still is making it's way into the market.

I had a machine with a rootkit on it (my parents laptop) file called srosa.sys - the only clue there was something wrong with the PC at all was it wouldn't run autocheck.exe and any file called chkdsk.exe was automatically deleted.

It also prevented the installation of any virus scan package - literally deleting and modifying files as they were installed.

Its like that hacker defender rootkit a lot of admins ran into a few years back (but didn't know about it) they were calling support about the information store crashing when you attached a file via the webmail interface. Here's the article in case anyone missed it:

http://blogs.msdn.com/jeremyk/archive/2004/07/19/187696.aspx

I think the scary thing is if anyone came along with a bug free rootkit that survived patching, didn't crash the OS or her applications/services and was undetectable most of us wouldn't think to look while the machine secretly sent all of our info to some machine in China.

BTW, Larry Osterman has an article called "AARDvarks in your code": http://blogs.msdn.com/larryosterman/archive/2004/08/12/213681.aspx

You can install the recovery console as a boot option:

http://support.microsoft.com/kb/307654

(You should have an I386 folder somewhere)

It is more complicated for Vista and later:

http://blogs.msdn.com/winre/archive/2007/01/12/how-to-install-winre-on-the-hard-disk.aspx

Nope. If you follow that link, you'll see you still need the Windows XP DVD to install the recovery console. Sadly, it was not uncommon for XP systems to be sold with no recovery console. My Toshiba laptop (I'll never buy another) did not come with a Windows XP DVD, merely a "product recovery disk" which wipes everything off the hard drive and does a fresh install. No recovery console available. Apparently there's a huge difference between buying a computer that comes with XP and buying a computer that comes with "XP installed."

You can install the recovery console as a boot option:

http://support.microsoft.com/kb/307654

(You should have an I386 folder somewhere)

It is more complicated for Vista and later:

http://blogs.msdn.com/winre/archive/2007/01/12/how-to-install-winre-on-the-hard-disk.aspx

http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx I've used this for years. It launches a command prompt (after requesting passwords) that is still you, but with admin privs. Makes all the stuff that doesn't work under runas work just fine.

The idea is not only that automated testing is good, but that testable code is fundamentally better because it needs to be loosely coupled.

Which is a faulty assumption. Coming from this perspective, you want to unit test everything, and so you need to make everything loosely coupled. But the latter is not free, and sometimes the cost can be hefty - where a simple coding pattern would do before (say, a static factory method), you now get the mess with interface for every single class in your program, abstract factories everywhere (or IoC/DI with its maze of XML configs).

Ultimately, you write larger amounts of code that is harder to follow and harder to maintain, for 1) a real benefit of being able to unit test it, and 2) for an illusory benefit of being able to extend it easier. The reason why that last benefit is illusory is because, in most cases, you'll never actually use it, and in most cases when you do use it, the cost of maintaining the loosely coupled code up to that point is actually much more than the price you'd have paid for refactoring it to suit your new needs if you left it simple (and more coupled) originally.

Also, it does promote some patterns that are actively harmful. For example, in C#, methods are not virtual by default, and it's a conscious design decision to avoid the versioning problem with brittle base classes. But "testable code" must have all methods virtual in order for them to be mocked! So you either have to carefully consider the brittle base class issue for every single method you write, or just say "screw them all" and forget about it (the Java approach). The latter is what most people choose, and, naturally, it doesn't exactly increase product quality.

Of course, this all hinges on the definition of "testable code". The problem with that is that it's essentially defined by the limitations of current mainstream unit testing frameworks, particularly their mocking capabilities. "Oh, you need interfaces everywhere because we can't mock sealed classes or non-virtual members". And then a convenient explanation is concocted that says that this style is actually "testable code", and it's an inherently good one, regardless of any testing.

Gladly, TypeMock is about the only sane .NET unit testing framework out there - it lets you mock anything. Sealed classes, static members, constructors, non-virtual methods... you name it, it's there. And that is as it should be. It lets you design your API, thinking of issues that are actually relevant to that design - carefully considering versioning problems, not forgetting ease of use and conciseness, and providing the degree of decoupling that is relevant to a specific task at hand - with no regard to any limitations the testing framework sets.

It's no surprise that some people from the TDD community are hostile towards TypeMock because it's "too powerful", and doesn't force the programmer to conform to their vision of "testable code". But it's rather ironic, anyway, given how TDD itself is by and large an offshoot of Agile, which had always promoted principles such as "do what works" and "make things no more complicated than necessary".

ODF produced by Office fails to work properly in any suite other than Office AFAIK, including OOo (as well as e.g. AbiWord, KOffice, Google Docs, etc.).

I believe that you're referring to the spreadsheet formulas problem (be sure to follow the links to blog posts there as well). Two things to note here: this only applies to formulas in spreadsheets; there is no standard covering those in scope of ODF 1.1 (which is the final published ODF standard at this moment - 1.2 is still a draft); and it wasn't a problem just between MSOffice and OO.org, there were other implementations which had incompatible formula representations - it's just that OO.org pushed all of the latter to conform to itself (specifically, to ODF 1.2 draft which it uses for formulas even in ODF 1.1 documents), but MSOffice stayed where it was.

There are other issues, but this is the single biggest one. Here is a list of all criticism with respect to implementation of ODF in MSOffice today. In particular, it's worth noting that there are no complaints referring to text documents in particular, so those are fully interoperable. The other two features that MSOffice doesn't properly support are change tracking, and password protection. I don't know the reason for not supporting password protection. With respect to change tracking, the official explanation is that it is notimplemented because it's underspecified and non-interoperable between other existing ODF 1.1 implementations.

Yet it is supposedly more "compliant" than OOo, due to a variety of technicalities.

I haven't seen any claims that MSOffice is more conformant to the spec than OO.org. The official claim is that it is merely conformant. Do you have any references for broader claims?

OTOH, ODF produced by OOo works in almost all of the other major suites. So, yes, it is trivial to do that, but no, it doesn't accomplish anything.

I think you're substituting definitions here. An open format, by definition, is the one that has an open specification - not the one that can be opened in a particular Office suite. In case of MSOffice, it implements ODF standard to the letter except for two features, it clearly defines the features that it doesn't implement, and it provides an open spec for those parts where the standard is underspecified, and format is implementation-defined. What this all means is that you can always fully extract any information contained in an ODF document saved by MSOffice by using only open specifications as a reference - there's no format lock-in.

ODF produced by Office fails to work properly in any suite other than Office AFAIK, including OOo (as well as e.g. AbiWord, KOffice, Google Docs, etc.).

I believe that you're referring to the spreadsheet formulas problem (be sure to follow the links to blog posts there as well). Two things to note here: this only applies to formulas in spreadsheets; there is no standard covering those in scope of ODF 1.1 (which is the final published ODF standard at this moment - 1.2 is still a draft); and it wasn't a problem just between MSOffice and OO.org, there were other implementations which had incompatible formula representations - it's just that OO.org pushed all of the latter to conform to itself (specifically, to ODF 1.2 draft which it uses for formulas even in ODF 1.1 documents), but MSOffice stayed where it was.

There are other issues, but this is the single biggest one. Here is a list of all criticism with respect to implementation of ODF in MSOffice today. In particular, it's worth noting that there are no complaints referring to text documents in particular, so those are fully interoperable. The other two features that MSOffice doesn't properly support are change tracking, and password protection. I don't know the reason for not supporting password protection. With respect to change tracking, the official explanation is that it is notimplemented because it's underspecified and non-interoperable between other existing ODF 1.1 implementations.

Yet it is supposedly more "compliant" than OOo, due to a variety of technicalities.

I haven't seen any claims that MSOffice is more conformant to the spec than OO.org. The official claim is that it is merely conformant. Do you have any references for broader claims?

OTOH, ODF produced by OOo works in almost all of the other major suites. So, yes, it is trivial to do that, but no, it doesn't accomplish anything.

I think you're substituting definitions here. An open format, by definition, is the one that has an open specification - not the one that can be opened in a particular Office suite. In case of MSOffice, it implements ODF standard to the letter except for two features, it clearly defines the features that it doesn't implement, and it provides an open spec for those parts where the standard is underspecified, and format is implementation-defined. What this all means is that you can always fully extract any information contained in an ODF document saved by MSOffice by using only open specifications as a reference - there's no format lock-in.

Let me see if I've got this straight. A great set of tools that run on Windows demonstrates how rubbish Windows is. A great set of tools that run on Linux demonstrates how fantastic Linux is.

This sounds a bit like Raymond Chen's post today: http://blogs.msdn.com/oldnewthing/archive/2010/02/09/9960102.aspx.

Microsoft resisted the inclusion of ODF import/export filters for some time, but finally decided to include them:

There are these things called plugins. And apparently anyone can write a plugin for reading and writing to their own format in MS Office. Its all the rage now. All the cool kids are doing it. BTW Microsoft isn't obliged to bundle support for any formats other than what they want. And yet at times, when the do (e.g. PDF) people (Adobe) sue them.

http://blogs.msdn.com/brian_jones/archive/2006/06/02/613702.aspx

"Ha ha M$ sucks they don't support X,Y,Z formats!"

"M$ monopoly!! Remove support for X,Y,Z format! Antitrust! Antitrust!"

No, it's called Visual Studio, actually.

Hmmm.....

A major difference is that IE is integrated deeper with the operating system, which means that flaws in IE can go deeper and have more serious effects

Internet Explorer is just an application and a set of libraries. They are included in the OS and reused in many places, but they cannot do more than any other user application. If iexplore.exe crashes it doesn't mean it will affect explorer.exe just because they both use mshtml.dll.

But the core problem lies in the fact that applications aren't normally started in an isolated sandbox with controlled access to the surroundings but with the access of the logged in user. So an user with full privileges will always get all apps having full privileges too, which they normally doesn't need.

Vista and newer Windows versions implement application integrity levels which run applications in a lower privilege level than the logged in user. When a user runs Internet Explorer (with Protected Mode) it actually runs under a very low integrity level which does not allow writing to user files. It is restricted to writing to special versions of folders like Cookies and Favorites, and must use broker processes to do anything that requires elevated access.

Does XP have a protected mode? That's the version of Windows most people use IINM. Is this a ploy to get people to upgrade from XP?

XP Users don't have access to protected mode, it relies on features present in Vista's security model.

Mandatory Integrity Control (MIC), a model in which data can be configured to prevent lower-integrity applications from accessing it. The primary integrity levels are Low, Medium, High, and System. Processes are assigned an integrity level in their access token. Securable objects such as files and registry keys have a new mandatory access control entry (ACE) in the System Access Control List (ACL).

* I'm not sure why Microsoft calls their use of MAC with integrity labels "MIC" instead... I guess it's because MAC is a NIH TLA.

User Interface Privilege Isolation (UIPI) blocks lower-integrity from accessing higher-integrity processes. For example, a lower-integrity process cannot send window messages or hook or attach to higher priority processes This helps protect against "shatter attacks." A shatter attack is when one process tries to elevate privileges by injecting code into another process using windows messages.

Microsoft, on the other hand, seems to take offense if you are not using their platform.

I guess it's why e.g. Office Live Apps officially support Firefox (including on Linux and Mac), and Safari.

You could say that using IE (or at least Silverlight) is nonetheless suggested, but then again, every time I log into GMail with my favorite browser (Opera), I see the ad urging me to try out Google Chrome...

Putting your swap file on a RAM-Disk has long been the stereotypical geek example of human stupidity...someone who knows just enough to be very dangerous.

Likewise declaring someone stupid when it turns out YOU are the one who needs to do a little learning. Quoting the Windows Engineering Blog:

Should the pagefile be placed on SSDs?

Yes. Most pagefile operations are small random reads or larger sequential writes, both of which are types of operations that SSDs handle well.

In looking at telemetry data from thousands of traces and focusing on pagefile reads and writes, we find that

        * Pagefile.sys reads outnumber pagefile.sys writes by about 40 to 1,
        * Pagefile.sys read sizes are typically quite small, with 67% less than or equal to 4 KB, and 88% less than 16 KB.
        * Pagefile.sys writes are relatively large, with 62% greater than or equal to 128 KB and 45% being exactly 1 MB in size.

In fact, given typical pagefile reference patterns and the favorable performance characteristics SSDs have on those patterns, there are few files better than the pagefile to place on an SSD.

Read that last sentence to yourself a few times, let it sink in. Now you can say sorry.

Additionally, if you have excess amounts of RAM available, every modern operating system will cache all disk reads, thereby offering instant access to your apps/files, the SECOND time you open them

Indeed useful. I get the last 2-3GB's of accessed files at RAM speed, if I'm lucky. That doesn't help boot time, that doesn't help sleep time, and that doesn't help when I launch an app for the first time in a while. All of which ARE helped greatly by using an SSD. Why can't I have both?

and it's not hard to make the case that more RAM is more beneficial for most common usage patterns.

Yeah, except I have one, and you're wrong. Caching is great for files you hit a lot, but you know what? My system drive has 40-50GB on it, and adding 40-50GB of RAM isn't really an option for most people, certainly not an economical one. You'll be lucky to get 10% of that in the cache - VERY lucky (seeing as all those media and data files will be pushing out the useful stuff you actually stand a chance of wanting to read again).

You seem to have a problem with SSDs, that's great, don't buy one. I wouldn't trade mine for 16GBs of RAM, never mind 8 (which is the equivalent cost).

It's a valid use case, but as you describe it, it means that every time you actually want to check the return value of fopen(), you use @ anyway. So whenever you use fopen() without @, you're effectively asserting that the file exists, and the following code will not have any checks (otherwise you'd use @ to avoid the warning message). If so, why isn't the use of fopen() without @ not a critical error that will prevent the following code from running, terminating the application - for example, by throwing an exception (as it happens in e.g. Java, C#, Python...)?

No, no, no. I check the return value every time, whether I use "@" or not. The return value check is for displaying a sensible message to the end user. In deployment, the PHP-generated message is *always* suppressed, "@" or no "@", so the return value check must always be there for every call.

I use "@" to suppress the PHP-generated debug message during development for specific calls where the failure is expected/harmless so that my HTML layout isn't hopelessly broken by those bogus warnings. They're suppressed because of the high false positive rate on that particular call. I omit the "@" on most calls because they should not fail even during development. That way, I get the detailed debug info during testing.

Either way, in the deployment phase, the "@" effectively occurs for every call, and the only error output comes as a result of checking the return value and generating a user-centric message.

If so, why isn't the use of fopen() without @ not a critical error that will prevent the following code from running, terminating the application - for example, by throwing an exception (as it happens in e.g. Java, C#, Python...)?

Because in deployment, that's the last thing you'd want. You want to trap the bad return value and display a user-friendly "Your changes could not be saved" formatted to match the site rather than "Java.lang exception blah blah blah" in black text on white or whatever.

Also, I generally need to identify that something went wrong as close as possible to the call because that's the only part of the code that knows precisely what was happening at the time, and thus that's the only place where a precise error message can be generated. It is also often necessary to roll back earlier operations when one part of a complex operation fails. That's not possible except right at that point in the code. If I can't just let the exception bubble up very far in my call stack, then there is no real advantage to using an exception over a return value.

Finally, I usually don't care why a call failed outside of the debug environment. I only care that it failed. With return values, I can typically handle every possible failed exit status with a single if statement. With exceptions, depending on how the particular function was designed, it can require multiply-nested try/catch blocks, one for each class of exceptions, all of which then have to set some flag so that later in the function you can treat each of them as being the same fundamental failure (or add an unnecessary function call whose sole purpose is to call the exception-throwing function, catch the exception, and return an exit status).

Also, exceptions are, in my opinion, simply a bad programming practice that leads to sloppy, buggy, insecure programming.

http://www.joelonsoftware.com/items/2003/10/13.html
http://silkandspinach.net/2005/06/14/exceptions-considered-harmful/
http://blogs.msdn.com/larryosterman/archive/2004/09/10/228068.aspx

One of the biggest reasons in the apparent jump in performance from Vista to Win7 was MS fixing the ungodly GDI problem that Vista had - there's a fairly thorough write-up about it here http://blogs.msdn.com/e7/archive/2009/04/25/engineering-windows-7-for-graphics-performance.aspx

Essentially, GDI in Vista scaled in a square/cube fashion with each new object taking up memory in both system and graphics memory - a double whammy for any machine with integrated graphics which hammered the memory bus and, if you didn't have enough memory, your swap file as well. Cue loads of machines slowing to a crawl with the usual excuse that they're "not powerful enough" for Vista. This was untrue - we had a couple of Vista workstations at work (needed 64bit) with 8GB RAM and if you open enough windows you'll still exhaust your memory.

Thankfully they fixed this for Win 7 and you can now boot in on a machine with 1GB of RAM and run it quite comfortably; the minimum I've managed to get Vista to run nicely in is 1.5GB with some tweaking (this was a friends laptop that was sold with vista and... 512MB of RAM, the poor lass. Took 15minutes to bot).

Executive summary: Vista was a bloated piece of crap.

Posting anon cos I've already modded this thread.

I remember reading an article with one of the Office team (my Google Fu sucks, maybe someone can find it?) talking about why they cooked up the ribbon.

http://blogs.msdn.com/jensenh/archive/tags/Why+the+New+UI_3F00_/default.aspx

Do you really think the ribbon was anything to do with usability? As far as I can see, it was about having a patentable UI element that OO.o and its ilk couldn't copy.

Before you propagate another conspiracy theory, watch this.

Please, watch this presentation. I was actually impressed by the amount of usability research they put into the Ribbon. Also, data show, that users like it, so enough of these horse laugh comments already.

Well it doesn't matter that nobody commented because they don't actually listen to feedback anyway. Take the example of when they changed the file tab order in VS2005 so that new tabs were added on the right. This change caused all your open file tabs to be pushed along making it impossible to keep track of the location of your file tabs and resulting in users wasting considerable amounts of time looking for files. The person responsible for this was Sara Ford and as you can see from the comments on her blog the response was overwhelmingly negative:

http://blogs.msdn.com/saraford/archive/2004/05/14/132065.aspx

Despite all these negative comments both her and Microsoft failed to take any action and no changes were made in the VS2005 service pack or in VS2008. Microsoft simply do not care what users think and and while the may put up the pretence of taking user feedback they always just do whatever they think is best. Sara Ford is a classic example of this and despite all the negative comments on her blog she was totally unable to accept that the change was for the worse. What's most absurd about this situation is that Sara Ford has written a book called "Microsoft Visual Studio Tips: 251 Ways to Improve Your Productivity". Given the she herself is responsible for considerably reducing the productivity of Visual Studio users through her absurd interface design I suspect the only use for this book would be as toilet paper.

Sara Ford is the personification of everything that is wrong with Microsoft today. When Windows 2000 came out I thought it was extremely good, offering the stability of NT and the software compatibility of 98 while running very fast on the hardware of the day. Since that time Sara Ford Syndrome has set in at Microsoft and the company has been over run with "soft skills" people who have these brilliant ideas to improve usability and in the process have rendered Microsoft's software completely unusable. The user interface changes Windows Vista/7 and Office 2007 have made using the software provably slower, are provably less consistent and are extremely wasteful of desktop space. I'd rather face torture than use Windows 7 or Office 2007 and many others feel the same way but despite the wave of negativity above these new user interface concepts Microsoft continue to push on regardless of their customers' opinions.

This time however it looks like it's going to cost them since they've split their operating system market into two camps with the vast majority in the XP camp. They're suffering revenue declines since people don't want their newer software, they're losing market share to Apple and they were forced to practically give Windows 7 away with their pre-order discount program to try and generate some positive hype. While 14 year olds may be rushing to Windows 7 with it's cool transparent Windows frames the corporate market is staying well away and have clearly indicated they have no interest in the new software Microsoft is trying to force on the market through their monopoly. By refusing to sell the software customers want and trying to force them to use software they don't it looks like Microsoft's latest monopoly abuse may be what finally brings their monopoly to an end.

Did you read the blog post where they solicited feedback? It had 9 comments in total. Among them was this comment from the author of the blog (4th comment):

I assure you we won't be changing that option [tab vs spaces] any time soon :-)

So they solicited comments on a blog that no one reads and immediately say they aren't planning to change anything when questioned. After saying they wouldn't be changing the option, no one complained. Wow, what due diligence.