Slashdot Mirror

The internal OS is WinCE, so the interface is either serial or USB.

The internal OS of what? The Kinect? Unlikely. Check the iFixit teardown. The device is pretty basic in terms of processing capabilities, relying on the Xbox to do most of the heavy lifting. Or are you referring to the Xbox? If so, you're still wrong. The Xbox 360 OS is not Windows CE. About the closest you can come to comparing it to another existing OS is by looking at its lineage. The Xbox 360 OS was derived from the original Xbox OS, which in turn was derived from Windows 2000. The extent that the Xbox 360 OS resembles Windows 2000 is almost certainly miniscule at this point, as it runs on an architecture that is not supported by the Windows codebase and does not need most of the core functionality of a Windows OS (shell, explorer, etc). There are probably some bits and pieces of Windows 2000 kernel code still lurking around somewhere, but aside from exposing DirectX and some minimal win32 functionality that's really about it.

Huh? The system hives live in %systemroot%\system32\config and the user hives live in the root of their profile. The system hive is split into like 5 different files, each named for the section they are. I'm not sure why you would want to look at the files, If you want to back them up there are better ways then a flat file copy, and if you want to delete them you aren't going to be able to because they will be in use.

Splitting the hives between the system directory and the user directory makes a lot of sense from a permissions perspective, to consolidate them would mean giving non-admins (able to write to their hive but not the systems) access to directory of files they can't edit and able to see the hives of other users. Putting it in the profile also firmly attaches it to the user it belongs to in a logical way. Either way other then data recovery or forensics, I've never needed to manual access the registry files, and no normal user ever would.

As for the lack of ability to clear settings, the cause is also a part of the solution. The cause is because admins running programs as admins can do whatever they want with the registry, because they are admins. Run a shitty installer, it spews shit everywhere, because it has admin rights and you ran it. The solution to shit in places it doesn't belong is to give an admin user the ability to use a program to modify the registry and change entries that don't belong. The registry cruft problem is entirely one of developer laziness, and you could have the same thing with config files just as easily. If MS forbade admins from modifying the registry in unapproved ways, people would scream murder, and actual admins (as opposed to retards running as admin) would have a legitimate point. A shitty program is a shitty program, nothing stops you from tracking the changes you make to the registry and undoing them 100% later, you could even store that info in the registry!. The registry also fully supports permissions, so you can fully control who can change what, put of course if someone runs a program as an user who has full access rights to everything, and that program writes all over everything, whose fault is that? MS gave you the tools, but you hung yourself. Don't like it, complain to whoever wrote the program, the OS did what it was told by an user with the access rights to do it, a situation could just as easily have happened with config files (and in the pre-registry days, it happened all the fucking time, which is why the registry was invented in the first place).

If you want to actually understand the reasoning behind the implementation of the registry, instead of blindly railing at it because you don't like the result when you let programs you don't trust do thing you dont want to it with wild abandon, look here: http://blogs.msdn.com/b/oldnewthing/archive/2007/11/26/6523907.aspx

The reality is there's nothing wrong with the registry as a design decision, and everything wrong with the security model of run everything as admins, but the reality is even though Windows gives you all the tools to run things NOT as admin, everyone does anyways, even people who should know better, and when they try to do anything to fix it, everyone calls them retarded and annoying because it gets in the way of running everything as admin.

The registry isn't bad because it's stored in binary form, or because it's heirarchical, or because it supports transactions, or because it has ACLs. These are good (or at least acceptable) things.

The registry is bad because it's global and forces a lot of configuration to be global as well. For example, COM components are registered globally, so only one DLL can be associatded with a class ID at a time. That's why you can only have one version of Internet Explorer installed on the same machine. Yes, users have their own registry subtress, but not every key can be configured under the user-specific heirarchy. Even a user-specific key can only have one value at a time for a given user. Unix systems, on the other hand, use environment variables to hold (or point to) configuration information, which results in a lot more flexibility.

Because registry values are global, application developers only consider the case of running one program at a time. If you want, say, two copies of Outlook, each with different settings, you'll need two separate users. A lot of programs don't even support multiple concurrent instances, which is maddening.

Another maddening side effect of the registry being global is that it's not possible to have the equivalent of NFS-mounted home directories under Windows. Say you have a domain user foo\bar on machines A and B. It's natural to want them to have the same %USERPROFILE% (read $HOME) on a fileserver somewhere, and on Unix, that works just fine. But under Windows, when the user logs into machine A, the system will lock ntuser.dat (the file containing the registry), which prevents the user logging in under machine B. Application-specific configuration files that are locked only during actual changes don't have this problem.

The global nature of the registry also makes it difficult to maintain application configuration: if you want to isolate the configuration information used by a program, you're essentially reduced to looking at procmon output and seeing what registry keys it touches. While in principle programs should limit themselves to storing information under HKLU\Software\Blah\..., in practice, they scatter stuff all over the registry, especially when they register COM stuff. You can't keep just, say, Word's configuration under version control.

When people say they hate the registry, what they mean is that they hate that Windows is not very well-modularized. Isolating one application's registry configuration is like removing one egg from an omelet.

A better model would have been to have application-specific registries, searched according to a PATH-like environment variable. In this scheme, when the system needed to, say, look up a COM class ID, it would just search each registry in sequence until it found the right one. Applications would simply store their configuration and registration information in their own registry, making management easy.

But like most Windows brain damage, this scheme wouldn't have worked on a 386SX with 4MB of RAM in 1995, which means it can't possibly be changed in 2010. As we all know, design decisions are irrevecorable and eternal (and I'm only half-joking).

Sure, if you'd like, leave the tinfoil hat on. I'm happy to provide data to MS (well, I would be if I used IE). I've become very interested in usability so it makes me jealous to read about all of the data they get to make decisions with. Just read this blog entry and look at all of the percentages they know about real world usage and how they used that for the IE9 UI overhaul.

A few examples:

• over 97% of IE sessions have 5 or fewer tabs
• 54% of people have 2 or fewer items on their Favorites bar (we ship with 2 by default)
• The most commonly used item in the Status bar was “Select Preset Zoom” used by 1.6% of people

Michael Kaplan has an interesting blog.

As unlikely as it sounds from context, he seems to care a great deal about correctness. It also paints a vivid picture of how hard Unicode is to get right.

Windows XP, Vista, Seven. Also Windows 98 and ME, but those two only if the external medium is a CD.

Windows 7 is not susceptible to this problem.

Companies and governments have massive amounts of custom code which runs only on IE6. The time, money, and effort to rewrite this would be absolutely huge.

Are you seriously suggesting that organizations just toss out a mission-critical bit of software either because it's old or proprietary? If so, then I think you have absolutely no understanding of what IT works like on a corporate scale.

I believe the entire Government of Canada has to use IE6 because they have apps that tie them to it. I suspect many really large organizations have this issue as well. It's not like these organizations can just stop using that software that they have.

If Microsoft didn't make stuff that was incompatible with everything else by design, companies wouldn't have this problem. But, as long as Microsoft continues to decide that their way is the best way, companies who have had to work around this are the ones who bear the burden.

It's also why Microsoft spends billions of dollars on backwards compatibility. Microsoft would love to just chuck out the crap on Windows and start afresh. Apple does this - if you don't use published APIs, you'll often find your app breaks in the next OS release. Microsoft would love to do this, but it's too hard.

The vast majority for the backwards compatibility is business - where Microsoft makes their money. Fixing bugs that can break an API is something they have to do carefully because it only has to break one critical application that can keep a company from upgrading, and that can easily be 10,000+ licenses we're talking about.

Some examples
http://blogs.msdn.com/b/oldnewthing/archive/2006/11/06/999999.aspx - 9000 install scripts to install various products for various employees. Now imagine the need to test, verify and fix. And they have source code.

And it's usually the developer's fault (most developers are stupid and do stupid things). In fact, you can count on a lot of developers (for all OSes) to do crap - pass wrong parameters in (that'll break should the function actually check), do horrendous coding practices (polling loops in your battery powered device), etc. And companies have it worse - between contractors and inhouse developers under pressure to "make it work" and "let's make it flexible and overdesign it".

There's a reason thedailywtf.com exists.

Here's another link showing how Microsoft has to patch against developers:
http://blogs.msdn.com/b/oldnewthing/archive/2007/07/23/4003873.aspx
Sometimes developers lie to the OS:
http://blogs.msdn.com/b/oldnewthing/archive/2004/02/11/71307.aspx

Ideally, Microsoft would do something and start fresh. Oh wait, they did. It was called Vista and panned by everyone because things broke.

Companies and governments have massive amounts of custom code which runs only on IE6. The time, money, and effort to rewrite this would be absolutely huge.

Are you seriously suggesting that organizations just toss out a mission-critical bit of software either because it's old or proprietary? If so, then I think you have absolutely no understanding of what IT works like on a corporate scale.

I believe the entire Government of Canada has to use IE6 because they have apps that tie them to it. I suspect many really large organizations have this issue as well. It's not like these organizations can just stop using that software that they have.

If Microsoft didn't make stuff that was incompatible with everything else by design, companies wouldn't have this problem. But, as long as Microsoft continues to decide that their way is the best way, companies who have had to work around this are the ones who bear the burden.

It's also why Microsoft spends billions of dollars on backwards compatibility. Microsoft would love to just chuck out the crap on Windows and start afresh. Apple does this - if you don't use published APIs, you'll often find your app breaks in the next OS release. Microsoft would love to do this, but it's too hard.

The vast majority for the backwards compatibility is business - where Microsoft makes their money. Fixing bugs that can break an API is something they have to do carefully because it only has to break one critical application that can keep a company from upgrading, and that can easily be 10,000+ licenses we're talking about.

Some examples
http://blogs.msdn.com/b/oldnewthing/archive/2006/11/06/999999.aspx - 9000 install scripts to install various products for various employees. Now imagine the need to test, verify and fix. And they have source code.

And it's usually the developer's fault (most developers are stupid and do stupid things). In fact, you can count on a lot of developers (for all OSes) to do crap - pass wrong parameters in (that'll break should the function actually check), do horrendous coding practices (polling loops in your battery powered device), etc. And companies have it worse - between contractors and inhouse developers under pressure to "make it work" and "let's make it flexible and overdesign it".

There's a reason thedailywtf.com exists.

Here's another link showing how Microsoft has to patch against developers:
http://blogs.msdn.com/b/oldnewthing/archive/2007/07/23/4003873.aspx
Sometimes developers lie to the OS:
http://blogs.msdn.com/b/oldnewthing/archive/2004/02/11/71307.aspx

Ideally, Microsoft would do something and start fresh. Oh wait, they did. It was called Vista and panned by everyone because things broke.

Companies and governments have massive amounts of custom code which runs only on IE6. The time, money, and effort to rewrite this would be absolutely huge.

Are you seriously suggesting that organizations just toss out a mission-critical bit of software either because it's old or proprietary? If so, then I think you have absolutely no understanding of what IT works like on a corporate scale.

I believe the entire Government of Canada has to use IE6 because they have apps that tie them to it. I suspect many really large organizations have this issue as well. It's not like these organizations can just stop using that software that they have.

If Microsoft didn't make stuff that was incompatible with everything else by design, companies wouldn't have this problem. But, as long as Microsoft continues to decide that their way is the best way, companies who have had to work around this are the ones who bear the burden.

It's also why Microsoft spends billions of dollars on backwards compatibility. Microsoft would love to just chuck out the crap on Windows and start afresh. Apple does this - if you don't use published APIs, you'll often find your app breaks in the next OS release. Microsoft would love to do this, but it's too hard.

The vast majority for the backwards compatibility is business - where Microsoft makes their money. Fixing bugs that can break an API is something they have to do carefully because it only has to break one critical application that can keep a company from upgrading, and that can easily be 10,000+ licenses we're talking about.

Some examples
http://blogs.msdn.com/b/oldnewthing/archive/2006/11/06/999999.aspx - 9000 install scripts to install various products for various employees. Now imagine the need to test, verify and fix. And they have source code.

And it's usually the developer's fault (most developers are stupid and do stupid things). In fact, you can count on a lot of developers (for all OSes) to do crap - pass wrong parameters in (that'll break should the function actually check), do horrendous coding practices (polling loops in your battery powered device), etc. And companies have it worse - between contractors and inhouse developers under pressure to "make it work" and "let's make it flexible and overdesign it".

There's a reason thedailywtf.com exists.

Here's another link showing how Microsoft has to patch against developers:
http://blogs.msdn.com/b/oldnewthing/archive/2007/07/23/4003873.aspx
Sometimes developers lie to the OS:
http://blogs.msdn.com/b/oldnewthing/archive/2004/02/11/71307.aspx

Ideally, Microsoft would do something and start fresh. Oh wait, they did. It was called Vista and panned by everyone because things broke.

You are exactly right. Their success is precisely what is holding them back on several fronts. Primarily, they don't want to disrupt their own business. The problem with this is that somebody else will.

Secondly, their support of legacy hardware and software is amazing. It's part of the reason they own the corporate market. It's also why that can't truly innovate. This is a great read directly from Microsoft that explains why their legacy is so crippling.

As long as I have to pay $99 ... to apps I develop on my own phone, I'm out

Discover Windows Phone 7 Development

1.Download the Windows Phone Developer Tools.
2.Create your Windows Phone app.
3.Test it in the Windows Phone Emulator.
4.Sell it in the Marketplace.

The - Free - Windows Phone Tools:

[Vista and Windows 7 Only]

Visual Studio 2010 Express For Windows Phone
Windows Phone Emulator
Silverlight For Windows Phone
XNA Game Studio 4.0
Expression Blend 4 For Windows Phone.

Visual Studio Express 2010 For Microsoft Phone

Channel 9

Windows Phone 7 Developer Training Kit

Getting started with Windows Phone
Silverlight for Windows Phone
XNA Framework 4.0 for Windows Phone

Access *is* limited to 2 billion bytes.

I assume they are mistakenly equating bytes with records.

"Expert mode" won't work. Neither will a dialog box.*

* - Sure that article says "The default answer is Cancel" but it should probably say "The default answer is whatever makes everything appear to work again" which in this case is OK. And the user actually won't have to fix anything in your scenario.

"Expert mode" won't work. Neither will a dialog box.*

* - Sure that article says "The default answer is Cancel" but it should probably say "The default answer is whatever makes everything appear to work again" which in this case is OK. And the user actually won't have to fix anything in your scenario.

"What will alleviate this somewhat, is moving entries for the most common advertising urls to the top of the entry list, and also using 0.0.0.0 instead of 127.0.0.1 in the "where to look" part. It is still going to read and process the entire file anyhow for each link on a webpage that is trying to load, for every page you open" - by Anonymous Coward on Tuesday October 05, @03:26PM (#33798318)

Wrong - you're NOT accounting for the fact that the local HOSTS file is just that: A FILE!

(And, what caches files? The local diskcache does, completely nullifying this point you just made... because subsequent reads of the HOSTS file if unchanged (like ANY file would be), will be read from the diskcache once the file is read by ANYTHING at least once, & yes, that includes the first read upon reload by the OS into the IP stack once the HOSTS file is read upon changing in the %WinDir%\system32\drivers\etc folder (std. location for it in Windows, since you noted this is about Windows here))

----

"that in Windows, if they install one of those HOSTS files, and have the DNSClient service enabled, they will slow down their entire machine, and not just their browsing experience" - by Anonymous Coward on Tuesday October 05, @03:26PM (#33798318)

Only with relatively "largish" hosts files though. Still, you CAN save RAM &/or CPU cycles too by turning off the DNS Clientside Cache even with smaller HOSTS files.

(It doesn't hurt anything either when you turn off the DNS Client Cache service, you surf just fine.)

"because for whatever reason, it isn't programmed to handle much over 10,000 entries, and starts causing noticeable performance degradation at about 8,000-9,000 entries. This unfortunately, is still a problem even under Windows 7, where they improved it ever-so-slightly to start choking up the entire machine at about 25,000 entries." - by Anonymous Coward on Tuesday October 05, @03:26PM (#33798318)

Some "FYI" for you: The "Reason why" is because it is programmed by the DNS Client Service code to read the data into a C/C++ struct, instead of a FIFO type buffer like a queue for example (a programmatic example), or even a redimmable array (those take time & cpu to "resize/reset" too, but not like you see in what happens with the current design of the DNS clientside cache as you noted in fact and it is true).

I have even notified MS of this over the years many times, and how to fix it, and once such example is here -> http://blogs.msdn.com/b/e7/archive/2009/02/25/feedback-and-engineering-windows-7.aspx?CommentPosted=true&PageIndex=3#comments but, they don't fix it. At least not yet.

(Fact is, I have a HOSTS file here that is now currently 902,393 entries long/24++mb in size on disk and I surf fine setup this way, without the DNS cache client running, & since 1997 or so on PC's @ least...)

----

"You neglected to mention though, that in Windows, if they install one of those HOSTS files, and have the DNSClient service enabled, they will slow down their entire machine, and not just their browsing experience" - by Anonymous Coward on Tuesday October 05, @03:26PM (#33798318)

Now, as to what you noted in MY post you replied to? Either of the sites that were shown to have good hosts files in the post you replied to DO tell users about when you use a larger hosts file, you may have to turn off the DNS client cache service.

(It's easy to do and mvps.org, one of the sites I noted for downloading a HOSTS file no less in my post you replied to, it has a batchfile that does it for you even)

You made it also seem like it always has to be turned off and that is NOT the case with all HOSTS files, only relatively "largish" ones.

APK

I made some informed assumptions

There is a difference between saying "I assume X is not possible" verses "X is not possible".

If you have a GPU that only supports DX9 then that is what it will use.

Which was stated by Microsoft already in channel 9 videos as I recall in which they mentioned slower routines are used for backwards compatibility with older hardware and certain shaders would not be available.

If anything, you giving that example serves to help my argument - as there is no reason why Shattered Horizon could not work on XP as clearly it happily works with DX9 cards.

Except for the fact that the software (Windows XP) doesn't do DX10, which is all I care about at this point and likely all the user of the game cares about too and before you suggest it, km-soft's poor DX10 implementation does not work with Shattered Horizon and has not worked with other DX10 games I own either.

If you want to talk about what's possible, yes, it's entirely possible to make any kind of software abstraction layer for anything API related for practically any mainstream platform out there. Doesn't mean it doesn't require a large amount of resources to produce it.

happily works with DX9 cards.

Not really, the FPS in the game wasn't that great until I upgraded to a later card model that had DX10 support (which amusingly had less video ram).

Windows 7 supposedly scales upto 256 cores.
See http://channel9.msdn.com/shows/Going+Deep/Mark-Russinovich-Inside-Windows-7/

Did anyone hear that Chris Wilson - Platform Architect of the Internet Explorer Platform team at Microsoft (and ex-Group Program Manager) moved on to Google yesterday ?

> I don't see Flash going anywhere for at least a decade

No one cares that Flash exists. What's important is that it be possible to develop tomorrow's web sites without having to use Flash, and that it be possible to browse the web at least somewhat reasonably without having Flash (e.g. not all sites need to work, but there should be sites in a given category that work without Flash). That's a somewhat realistic goal right now; for example very few banks require Flash (though some do).

> Silverlight won't have the install base of HTML5

The goal is to keep it that way, yes.

> Apple doesn't have enough influence to change the direction of the web.

You apparently haven't had to deal with the "if it's on a cell phone it must be Webkit" mindset of developers of "mobile" sites. See the part dealing with -webkit-text-size-adjust at http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx which Microsoft was forced to take out later. Note that there have been calls for Gecko to similarly add support on mobile for some of the -webkit-* stuff Apple has been pushing people to use. Those calls have been resisted so far, but as for the future.... who knows.

(many of) the journals they publish in only accept their submissions in MS Word format

RTF is an "MS Word format" because Word 2007 will read it. As of Office 2007 SP2, so is ODF.

See if the information at http://blogs.msdn.com/b/oldnewthing/archive/2010/08/04/10045651.aspx changes your mind.

Actually, Microsoft does fix bugs based on these reports. http://blogs.msdn.com/b/oldnewthing/archive/2010/08/04/10045651.aspx

Do you really think that Microsoft has a team of people searching through these reports and actively fixing bugs based on them? It's more a metric of how bad a known bug is, that is, how many people are reporting crashes from known bug A as opposed to known bug B.

That Windows Error Reporting actually has an unexpected side effect - spikes in crash reports often indicate a new virus is on the loose...
http://blogs.msdn.com/b/oldnewthing/archive/2008/05/21/8525411.aspx

compiled byte code in the utilities they use would do you little good unless you were extremely patient

Many people in the Windows OS team only debug at assembly level. For e.g. Raymond Chen.

http://blogs.msdn.com/b/oldnewthing/archive/2004/11/11/255800.aspx

"1. Once the optimizer has messed with your code source level debugging falls apart.

2. Most debugging is done remotely. When you have to debug a customer's machine 5000 miles away over a 56k modem, you can't tell them, "First, I want you to install Visual Studio on your domain controller..."

3. Installing a GUI debugger on the test machine changes the system configuration and therefore influences the test itself. Imagine if Windows XP had some horrific bug that goes away when you install Visual Studio. If all test machines had Visual Studio installed on them, then this bug would never be found!

4. Just today I had to debug a problem that occurred only immediately after installing the OS. No chance to install VS even if you wanted to.

5. If you're debugging the OS itself (say the window manager), then you can't use a GUI debugger since it needs the window manager to draw its UI!

Conclusion: Since so much debugging is done in situations where GUI debugging is not possible, you are quickly forced to become an expert at command line debugging. At which point the incremental benefit of a fancy debugger is rather small.

"You can't possibly debug any significant size project in this fashion."

Shhh, don't tell the Windows team. Not all debugging is done at asm-level, but a significant chunk is. They'd be pretty disheartened to learn that what they're doing is impossible.

It sucks less

Microsoft created a liberal dynamic library search path that allows (or even encourages) applications to not fully specify DLL locations. Now, after the fact, they publish this security statement saying not to use the dynamic library searching they documented previously.

So basically, your suggestion is to design an OS that ensures that it is secure by taking away API calls that could be misused in a way that compromises security? By your own admission, it is a documented specification, and it is behaving exactly as it is intended to do so. It isn't a "bug" in the API, it's misuse by various developers. However, Microsoft is at fault for how developers (its own or 3rd-party) misuse an API call that is fully documented and behaving exactly as intended? This makes absolute, perfect sense.

It is of course Microsoft's fault. They didn't consider security at all when loading DLLs, and now they are blaming applications that implemented the documented specification.

Yes, they are blaming applications that have incorrectly used the documented specification. And, they have provided the capability to control remote loading of DLLs through a patch that can be targetted at individual applications or the entire OS. What more can reasonably be done?

The bottom line is that Windows was never designed to be secure, it was designed to have the most functionality, and trying to patch every hole now is almost impossible. Generally, when code reaches this level of complexity and brittleness, it is often the best course to start all over.

And this is factually wrong. Windows NT (as opposed to Windows) was designed from Day 1 to be secure. You can argue whether they succeeded in developing a secure OS, and that might be a far more interesting debate, but to argue that it was never designed to be secure is incorrect. This is a fact of historical record. I'd argue that earlier versions of Windows NT were significantly flawed from a security perspective while modern versions (Vista and newer) are significantly improved, but that's another debate.

Essentially, your entire argument is that it is Microsoft's fault for providing a documented API that can be misused. I'll grant the defaults could have been chosen better, but competent programmers need to be aware of these issues. I'm mildly surprised it's getting the coverage it is, as this isn't some brand new attack; this issue has been known about for some time and not gotten a lot of coverage because it simply isn't that big a deal and is not a flaw in the underlying OS. For example, this blog post from early 2008 covers the issue (and was linked in some more recent blog posts): DLL Preloading Attacks

Win95 was 32-bit "OS" bolted on DOS. OS/2 was 32-bit from the ground up.

Argh, not this again. Windows 95 used DOS basically as a bootloader and not much else.

http://blogs.msdn.com/b/oldnewthing/archive/2007/12/24/6849530.aspx (Even references Slashdot bait, thanks to myths perpetuated on here).

Once in protected mode, the virtual device drivers did their magic. Among other things those drivers did was "suck the brains out of MS-DOS," transfer all that state to the 32-bit file system manager, and then shut off MS-DOS.

I don't know when Freecell was first released. It was part of win32s, but I can't find out when the first version of that thing shipped.

1. http://en.wikipedia.org/wiki/FreeCell_(Windows)#History
2. http://en.wikipedia.org/wiki/Microsoft_Entertainment_Pack#32-bit_versions
3. http://channel9.msdn.com/shows/History/The-History-of-Microsoft-1991/

So MEP vol 2 was released on 30 September 1991.

See also this blog post from Microsoft's Raymond Chen.

Great quote from the comments to this article, explaining the big problem with Windows:

Me: "I thought I installed antivirus software, but it's not running?"

Mom: "Oh, I uninstalled that - it kept keeping me from opening my emails"

Just about all the major problems with Windows are there: security as a bolt-on, ordinary users having administrator rights, Windows viruses, annoying operating system nag messages, and of course, a liberal dose of user cluelessness with that administrator access.

While NT was a huge break from the original Windows, this is incorrect. Pre-NT co-existed with DOS in some ways, but Windows 95 did have its own device drivers.

See also this blog post from Microsoft's Raymond Chen.

Your first point? I've known about that since 1999 & Windows 2000!

(Ask the moderator DosFreak at either Arstechnica OR NTCompatible.com (iirc, he mods both))

OR

Some of the "proofs to that effect" below I cite, because me?

I back what I state with verifiable evidences, unlike most others here, yes, even despite the fact I am degreed in the art & science of computing & far more (16++ yrs. of pro experience, commercial code to my credit, & code + ideas that were FINALIST work in MS' Tech Ed 2000 & 2001 consecutively, as well as my appearing for softwares I wrote in reputable publications in computing such as Windows IT Pro Mag 10x or more from 1996-2008).

Here we go:

----

"See here (and other google results if you care) for Microsoft MVPs stating that having a large HOSTS file is a known cause for the DNS Cache service (which handles that file) consuming 100% CPU" - by psm321 (450181) on Tuesday August 10, @11:29AM (#33204740)

#1 ON DNS Client Cache (MS one's faulty as hell):

New NEWS with proof: I am the guy that brought that up to Microsoft, directly, here (as Alexander Peter Kowalski (hence, my "APK" I sign posts with here)):

http://blogs.msdn.com/b/e7/archive/2009/02/25/feedback-and-engineering-windows-7.aspx?CommentPosted=true&PageIndex=3#comments

and earlier here to my other "naysayers" as well in THIS VERY EXCHANGE NO LESS:

http://it.slashdot.org/comments.pl?sid=1743902&cid=33149084

And many MANY times here in posts on HOSTS files too!

So, yes, I am QUITE aware of it, but there is a valid workaround~!

(It's, your local diskcache, since it assumes that task of caching HOSTS file data as it does any other file on disk into its FIFO buffers in RAM in fact, actually NEGATING the need for the faulty design of MS' local DNS clientcache in fact)

VERY IMPORTANT POINT FOR YOU ESPECIALLY : That all said & aside? Well, so you can see, I not only avoid wasting RAM, CPU, & other forms of I/O on a faulty system like DNS servers, but also the faulty DNS clientcache service in Windows too by using HOSTS files!

(DOUBLE BONUS!)

And not only to the head of MS dev teams in S. Sinofsky on the note of HOSTS files and DNS issues (clientside cache to MS only though on DNS), but before that to MS senior mgt. in Foredecker here http://slashdot.org/comments.pl?sid=1467692&cid=30384918 on this very website also before your article in fact, ask him yourself, because he conceded my points there & it is quoted!

(Foredecker also happens to be senior MS mgt. & VP head of "Windows Client Performance Division" because he POSTS HERE in fact - & all my points, & again he HAS his CSC BS? HE agreed with me, albeit not until I had to drag it all out of he on all points I made here as well... ask he yourself!)

#2 ON DNS clientside faulty cache for MS

(Yes, I have tested not only programmatic loads of diff. hosts file setups to verify the math theory, but tests for even when the DNS client cache is turned off, the local diskcache takes over on that account keeping performance high, as it does for ANY file (vs. MS' faulty DNS cache client))

----

"DNS servers were designed for that. You are abusing HOSTS by using it to replace the functionality of a DNS server. Because the OS is not designed for such huge HOSTS files, it will be slower than using DNS as intended (even for example a DNS server running on your local machine to blackhole all those domains for you) - by psm321 (450181) on Tuesday August 10, @11:29AM (#33204740)

#3 ON DNS SERVERS FOR SECURITY AND

RFID toll tokens have already been successfully used to prove location and travel:
http://blogs.msdn.com/b/ericfitz/archive/2007/08/10/ez-pass-logs-used-in-divorce-cases.aspx

The one space/two space debate is really about fundamentals of good typhography when doing text layout. It has everything to do with the overall colour of the block of text you're setting. But I'm no expert. Bill Hill is. He knows more about fonts and typography than likely anyone posting in this quite silly thread, including me. He spoke at length about spaces after periods on Channel 9 back in 2004.

Want to read more? Then pick up a copy of The Elements of Typographic Style by Robert Bringhurst. It's pretty much the bible of typography and goes into all sorts of wonderful detail on the colour of text, how to lay out pages, when to use em dash vs. en dash vs. hyphen, lowercase numbers, etc. And yes, Mr Bringhurst even talks about spacing after periods.

Ironically, Microsoft actually uses fuzz testing to test for security problems in its products.

1. Turn on InPrivate Filtering by hitting Ctrl+Shift+F 2. A registry key will be created: HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Safety\PrivacIE 3. Create a DWORD (32-bit) called StartMode under this key 4. The following values for StartMode correspond to settings for InPrivate Filtering: (Off = 0, Auto = 1, Manual = 2)

So they'll sink $4-5 billion building hardware, software, branding, and (presumably) a market/network? Yeah, maybe.

Or it could be a Zune phone, replete of velvety brownness and the ability squirt.

Actually, it would be fun to see them flop about in a costly and humiliating manner. Sure the Xbox has turned a profit for some select quarters but I reckon they're still down a few billion overall. Does anyone know how the Zune is fairing?

I, for one, welcome Windows Live 7 Professional Phone Xtreme Crispy Chunky Ranch-Bacon. If it worked for Vista and Hotmail, well, they could work similar magic with a homegrown phone.

(We can still make fun of Vista and Hotmail, right? And what the fuck is with those Hotmail ads? They make less sense than the Seinfeld ones.)

Users don't read dialogs. They try to do whatever possible to dismiss it as quick as possible, without reading it. http://blogs.msdn.com/b/oldnewthing/archive/2003/09/01/54734.aspx http://arstechnica.com/security/news/2008/09/study-confirms-users-are-idiots.ars

As well particularly verbose errors are ignored. The whole thing is a big problem because it makes it very difficult to protect users against themselves if they willingly agree to install malware, and ignore security warnings. This is why fake AV software "XPAntivirus 2019" and the like are so successful.

Microsoft couldn't get basic speech to text to work reliably

For what it's worth, the issues with Vista's STT demonstration were explained pretty soon after the incident. Given the nature of the problems, most people at the time anticipated a training/hardware issue. Of course, that doesn't change how funny it was :)

As it happens, Vista and Win7's voice recognition is actually pretty good for software bundled with the OS.

None. (Contary to what others say, I assure you the reason is licensing limitations. XP is license limited to 4GB of RAM.)

There ARE issues where DEP enabled XP (i.e., XPSP2) will not use more than 4GB of physical address space[1]; although I just read a blog post that suggests manually enabling /PAE on the boot.ini might sidestep that (URL below). (PAE was not the norm for XP pre SP2; so many consumer-grade device drivers did not handle physical addresses >4GB and just crashed. With SP2, adding NoExecute (NX) meant that PAE was generally on and all sorts of device drivers had issues with this - apparently. Thus, XPSP2 normally runs in a truncated PAE -- PAE is on, but nothing over 4GB is used.)

http://blogs.msdn.com/b/carmencr/archive/2004/08/06/210093.aspx

[1] Once you allow for PCI, enforcing a maximum of 4GB of physical address space means 4GB of RAM is usable. Typically, 3.5GB.

if (MAJOR_VERSION >= 6 && MINOR_VERSION >= 1)
{
      DoXPStuff();
}
else
{
      Fail();
}

And then we end up with messes like this: http://blogs.msdn.com/b/oldnewthing/archive/2004/02/13/72476.aspx

the GC was supposed to solve all problems. I recall a microsoftie telling us how he could never get his reference counts correct, and how he could never write an app without circular references, and that the all-new .NET with added GC would magically solve all these problems.

That's what it was like when .NET appeared, it was pushed as a silver bullet to all problems. We had to fight tooth and nail to get them to add IDispose back then, they (MS) didn't seem to think it was necessary, after all, we had Finalisers. IDispose was just a design pattern back then BW, no using blocks to make it into a pretend-RAII mechanism that is used so often now, just imagine if you didn't have using.

RAII is the better solution BTW, so much so that its copied as much as it can be in .NET today.

You think they understand resource issues in .NET, have a read through this blog entry. Nice comment: or how we were forced to providing such a useful construct, here's a detailed writeup on SafeHandle. Took MS 3 years to figure out reference counts aren't a dead construct after all.

Ruby - its a clean language, nicely laid out, easy to write for, got some excellent ideas about naming and automatically matching one thing to another (ok requires Rails too). It may not look like what you expect, but frankly, C# code looks like C sometimes, and I'm sure you don't want to say C is a clean language (it is, IMHO, unless abused). Maybe you think clean = pretty, but I'm an engineer, clean = elegant = efficiency through simple yet powerful consructs.

I understand about strcpy being unsafe, but strncpy() has the size parameter, so it will only copy bytes.

The problem with strncpy is that it is not guaranteed to null-terminate - it pads with '\0' at the end if there is space in the destination buffer, but if the length matches precisely, it will not pad. So to use it safely, you need to put a '\0' at the very end of the buffer yourself, and tell strncpy that there is 1 less byte there than there actually is, so that the terminator is never overwritten. Again, people tend to get this wrong more often than not.

In addition, it is also time-inefficient due to the fact that it fills the entire remaining buffer with '\0', rather than just adding a single `\0` to terminate.

Indeed, OpenBSD also introduced strlcpy (and friends) for precisely these reasons.

But Scala uses a functional paradigm

No, it's hybrid OO/FP - which has been all the rage lately - with OO emphasized over FP.

For comparison, F# is also hybrid OO/FP, but the balance is more towards the FP side of things.

An aside: How many .Net developers use F#, the functional programming equivalent there?

Well, these days, I consider F# to be the default language for anything that has to do with lexing/parsing text or walking trees on .NET.

Inside MS itself, it's used for some parts of the ad platform for Bing. Outside, it has some success in financial/banking.

But, anyway, trying to compare the pairings of Java/Scala vs C#/F# is not particularly meaningful, because C# has considerably more FP and FP-inspired language features compared to Java (most notably, it actually has proper closures), so even where FP makes more sense, you can stick to C# longer than you could stick to Java without things becoming awfully inconvenient.

Are you using C# 4.0, which supports covariance and contravariance?

Uh, well it depends on something that isn't clear to me: Is >canvas< and the specific features thereof they're talking about IE9 specific, or is it part of the html5 standard? If it's part of the standard, but hardware accelerated through IE9, then that's probably okay. Even if it means developers assume an IE9 target and do more with the tag than would be practical to do on non-accelerated browsers. I mean sure IE has a, shall we say, privileged position on Windows, but it's not like other apps can't access the graphics hardware.

If it's IE9-specific extensions to html5, then yeah, that's bullshit.

All the new IE9 features they've showcased are in open standards and already implemented interoperably by other browsers. IE9's <canvas> demos work perfectly fine in all other browsers – but they're much slower due to the lack of hardware acceleration. Actually, IE9's Standards Mode even removes some proprietary IE extensions from earlier versions (e.g., JS extensions; scroll down to "Same Script, Same Markup").

Microsoft is now actually trying to beat the other browsers by being actually better, as they did with IE6, so they can regain lost market share. They have the advantage that their browser only works on one platform, so they can rely on Vista/7-only APIs like Direct2D and DirectX 10 while other browsers need to support OpenGL, DirectX 9, etc.

In other words: be afraid. The enemy has learned from its defeat.

The video tag will work basically like any MS video setup does: If Windows knows how to play something, meaning the DirectShow codec is installed, then it'll do so.

That's actually not the case in IE 9: for security reasons (well, OK, a bunch of reasons, but reading between the lines, security's the big one), arbitrary codecs aren't supported within the browser. It'll ship only with H.264 support, and they've announced that WebM will be supported as an add-on, but that's it at the moment.

I don't really blame them. It sounds like sandboxing DirectShow codecs might not be as easy as it could be, and IE cops enough security flack as it is (mostly deserved, of course).

The video tag will work basically like any MS video setup does: If Windows knows how to play something, meaning the DirectShow codec is installed, then it'll do so.

That's actually not the case in IE 9: for security reasons (well, OK, a bunch of reasons, but reading between the lines, security's the big one), arbitrary codecs aren't supported within the browser. It'll ship only with H.264 support, and they've announced that WebM will be supported as an add-on, but that's it at the moment.

I don't really blame them. It sounds like sandboxing DirectShow codecs might not be as easy as it could be, and IE cops enough security flack as it is (mostly deserved, of course).

"The scripting engine in Chrome is at least twice as fast as the one in IE" - by istartedi (132515) on Sunday June 27, @06:02PM (#32711456)

See the results there for what's stated in my subject-line above, it's VERY CURRENT (this week in fact):

http://blogs.msdn.com/b/ie/archive/2010/06/23/html5-native-third-ie9-platform-preview-available-for-developers.aspx

("Read 'em & weep"... & that's ONLY OPERA's BETA CODE FOR THEIR NEXT RELEASE mind you - it's only going to be faster once it's OUT OF BETA (once excessive err traps &/or debug stuff is outta it's codebase))

So - For SPEED?

Opera leads there, & for the LONGEST TIME also, plus on most ALL FRONTS for things "web" (scripting AND std. HTML work)... here are some evidences of that, over time:

http://www.howtocreate.co.uk/browserSpeed.html

and

http://crave.cnet.co.uk/cnetuk/crave/software/0,39029471,49302491,00.htm

AND

http://nontroppo.org/timer/kestrel_tests/

(Opera "rocked the planet" in those cases... bigtime (& ESPECIALLY ON THE MOST USED PLATFORM THERE IS, BAR-NONE, FOR PC-COMPUTING: Windows!))

APK

P.S.=> On the note of security as well, in favor of Opera? It's usually always listed with ZERO known security vulnerabilities over @ SECUNIA.COM also (here are today's results on that note in fact):

INTERNET EXPLORER 8.x VULNERABILITIES STATS:(06/27/2010)

http://secunia.com/advisories/product/21625/?task=advisories

Unpatched 31% (4 of 13 Secunia advisories)

---

FIREFOX 3.x VULNERABILITIES STATS:(06/27/2010)

http://secunia.com/advisories/product/25800/?task=statistics

Unpatched 9% (1 of 11 Secunia advisories)

----

GOOGLE CHROME 5.x VULNERABILITIES STATS:(06/27/2010)

http://secunia.com/advisories/product/30134/

Unpatched 0% (0 of 2 Secunia advisories)

---

OPERA 10.x VULNERABILITIES STATS:(06/27/2010)

http://secunia.com/advisories/product/26745/?task=statistics

Unpatched 0% (0 of 7 Secunia advisories)

---

(Once more/again, albeit on the note of security vs. speed above: "Read 'em & weep"...)

Opera ROCKS, period (or, do the stats above make me a liar? I think not...)! Opera shows less security vulnerabilities in current builds than FF does (& less than IE, & IE still has known security issues).

Plus, Opera's been able to pass the "ACID TESTS" (ACID2 specfically) for compliance to web-based standards since version 6.x iirc, & it was (iirc) actually the FIRST BROWSER (not development kit) to do so, but when counting dev kits, it was 2nd... correct me if I am "off" here on this last point though, guys, & thanks.

APK

P.S.-> Opera has a BIG "share-of-market" on MOBILE DEVICES as well, & is big in EUROPE (though stats don't tend to show it, because like many others, I tend to "IDENTIFY AS IE" in Opera, so I get somewhat better "IE based" page renderings on SOME sites (this happens, too bad) & that's something others seem to overlook QUITE A BIT too)...

Once more, imo @ least? Well - Opera's great!

I.E.-> It took me away from being a FireFox user primarily in fact, because of it (& FF + IE have copied Opera's features RAMPANTLY over time (e.g.-> Tabbed Browsing anyone? As far as ADDONS also?? Heh, a LOT of w

They don't; MS pays in far more than they get from MPEG-LA:

Microsoft pays into MPEG-LA about twice as much as it receives back for rights to H.264.

That's not making money. Having patents in the pool doesn't mean you profit from it, which is what some stupider slashtards seem to assert when the topic comes up - that Apple (and Microsoft) somehow make money by supporting H.264.

There are still lots of people 'stuck in the 80's' interested in building things from scratch. We have a series of articles on building a bicycle computer using .NET and Visual Studio there you can get as close as you want to the hardware without giving up the tools you are familiar with on the desktop. http://blogs.msdn.com/b/netmfteam/