Slashdot Mirror

Even though Windows NT uses UTC internally, the BIOS clock stays on local time. Why is that?

There are a few reasons. One is a chain of backwards compatibility.

In the early days, people often dual-booted between Windows NT and MS-DOS/Windows 3.1. MS-DOS and Windows 3.1 operate on local time, so Windows NT followed suit so that you wouldn't have to keep changing your clock each time you changed operating systems.

As people upgraded from Windows NT to Windows 2000 to Windows XP, this choice of time zone had to be preserved so that people could dual-boot between their previous operating system and the new operating system.

Another reason for keeping the BIOS clock on local time is to avoid confusing people who set their time via the BIOS itself. If you hit the magic key during the power-on self-test, the BIOS will go into its configuration mode, and one of the things you can configure here is the time. Imagine how confusing it would be if you set the time to 3pm, and then when you started Windows, the clock read 11am.

"Stupid computer. Why did it even ask me to change the time if it's going to screw it up and make me change it a second time?"

And if you explain to them, "No, you see, that time was UTC, not local time," the response is likely to be "What kind of totally propeller-headed nonsense is that? You're telling me that when the computer asks me what time it is, I have to tell it what time it is in London? (Except during the summer in the northern hemisphere, when I have to tell it what time it is in Reykjavik!?) Why do I have to remember my time zone and manually subtract four hours? Or is it five during the summer? Or maybe I have to add. Why do I even have to think about this? Stupid Microsoft. My watch says three o'clock. I type three o'clock. End of story."

(What's more, some BIOSes have alarm clocks built in, where you can program them to have the computer turn itself on at a particular time. Do you want to have to convert all those times to UTC each time you want to set a wake-up call?)

Here you go... performance comparison of unmanaged C++ vs .NET

I think you might be confusing .NET's JIT compilation with the way that Java code is interpreted. Check out this link for more information on the .NET JIT process.

...And if you thought Sharepoint support for Excel was cool, wait till you see the server-side Excel Services that Microsoft's introducing with Excel 2007.

The hypocrisy on this site is astounding.

Consider this:
1. Adobe's market share in PDF creation software is similar to Microsoft's marketshare in desktop OSes for intel-compatible CPUs. Therefore, one could argue that Adobe has a "monopoly" in pdf creation software (not 100% share, but nearly so). But to keep some of you from bitching about the use of the term "monopoly" in this case, I'll use the term "quasi-monopoly".

2. Adobe, wanting to protect their "quasi-monopoly", was willing to allow Microsoft Office 2007 to export PDF if Microsoft charged extra for that functionality so as to not undercut the price of Adobe's own PDF creation software. In other words, Adobe wanted to engage in price-fixing with Microsoft in order to protect Adobe's quasi-monopoly. That is what you guys are supporting! Do you really want to go down that road? Surely you'll want to rethink your position, or does your hypocrisy really go that far?

3. Microsoft wasn't bastardizing PDF. What would be the point, since Microsoft is not producing any PDF reader? Since Microsoft isn't creating their own reader, any PDF document producted by Microsoft Office would have to be readable by other readers (and printable by printers), so why bastardize the format? Think logically.

4. If you want to see an example of the PDF produced by Office 2007, try Office 2007 beta 2. Or you can read the PDF version of the latest draft of the OpenXML ECMA spec, a PDF document that was created by Office 2007 beta. Guess what, it's perfectly readable by Acrobat Reader and any other PDF compliant reader.

5. Regarding XPS, XPS is a PDF competitor based on XML, but includes many advances over the current PDF spec (though future PDF specs may add such advances). XPS is part of Vista; XPS's role in Vista is similar to PDF's role in Mac OS X. Microsoft has shared with Adobe info on XPS for several years. Now Microsoft, bending over backwards to allay Adobe's hypocritcal paranoia, is removing from Office 2007 built-in support for both PDF and XPS. Furthermore, Microsoft is leaving it up to OEMs as to whether they want to include XPS support in Vista itself (except for XPS's role as a spool file format for Vista's printing enhacements).

6. Lastly, Microsoft is still going to provide PDF and XPS export support in Office 2007 as free downloadable plug-ins. Adobe's still pissed about this because they want Microsoft to charge for the plug-ins (more of the price-fixing scheme that you guys are supporting).

See these links for sources of the above info:
http://blogs.msdn.com/andy_simonds/archive/2006/06 /02/XPSAdobe.aspx
http://blogs.msdn.com/brian_jones/archive/2006/06/ 02/613702.aspx
http://blogs.msdn.com/brian_jones/archive/2006/06/ 03/616022.aspx

Lastly, please don't you (or the state of MA) ever refer to PDF as "open" in the future. If it's not open for all, then it's not truly open, period.

The hypocrisy on this site is astounding.

Consider this:
1. Adobe's market share in PDF creation software is similar to Microsoft's marketshare in desktop OSes for intel-compatible CPUs. Therefore, one could argue that Adobe has a "monopoly" in pdf creation software (not 100% share, but nearly so). But to keep some of you from bitching about the use of the term "monopoly" in this case, I'll use the term "quasi-monopoly".

2. Adobe, wanting to protect their "quasi-monopoly", was willing to allow Microsoft Office 2007 to export PDF if Microsoft charged extra for that functionality so as to not undercut the price of Adobe's own PDF creation software. In other words, Adobe wanted to engage in price-fixing with Microsoft in order to protect Adobe's quasi-monopoly. That is what you guys are supporting! Do you really want to go down that road? Surely you'll want to rethink your position, or does your hypocrisy really go that far?

3. Microsoft wasn't bastardizing PDF. What would be the point, since Microsoft is not producing any PDF reader? Since Microsoft isn't creating their own reader, any PDF document producted by Microsoft Office would have to be readable by other readers (and printable by printers), so why bastardize the format? Think logically.

4. If you want to see an example of the PDF produced by Office 2007, try Office 2007 beta 2. Or you can read the PDF version of the latest draft of the OpenXML ECMA spec, a PDF document that was created by Office 2007 beta. Guess what, it's perfectly readable by Acrobat Reader and any other PDF compliant reader.

5. Regarding XPS, XPS is a PDF competitor based on XML, but includes many advances over the current PDF spec (though future PDF specs may add such advances). XPS is part of Vista; XPS's role in Vista is similar to PDF's role in Mac OS X. Microsoft has shared with Adobe info on XPS for several years. Now Microsoft, bending over backwards to allay Adobe's hypocritcal paranoia, is removing from Office 2007 built-in support for both PDF and XPS. Furthermore, Microsoft is leaving it up to OEMs as to whether they want to include XPS support in Vista itself (except for XPS's role as a spool file format for Vista's printing enhacements).

6. Lastly, Microsoft is still going to provide PDF and XPS export support in Office 2007 as free downloadable plug-ins. Adobe's still pissed about this because they want Microsoft to charge for the plug-ins (more of the price-fixing scheme that you guys are supporting).

See these links for sources of the above info:
http://blogs.msdn.com/andy_simonds/archive/2006/06 /02/XPSAdobe.aspx
http://blogs.msdn.com/brian_jones/archive/2006/06/ 02/613702.aspx
http://blogs.msdn.com/brian_jones/archive/2006/06/ 03/616022.aspx

Lastly, please don't you (or the state of MA) ever refer to PDF as "open" in the future. If it's not open for all, then it's not truly open, period.

The hypocrisy on this site is astounding.

Consider this:
1. Adobe's market share in PDF creation software is similar to Microsoft's marketshare in desktop OSes for intel-compatible CPUs. Therefore, one could argue that Adobe has a "monopoly" in pdf creation software (not 100% share, but nearly so). But to keep some of you from bitching about the use of the term "monopoly" in this case, I'll use the term "quasi-monopoly".

2. Adobe, wanting to protect their "quasi-monopoly", was willing to allow Microsoft Office 2007 to export PDF if Microsoft charged extra for that functionality so as to not undercut the price of Adobe's own PDF creation software. In other words, Adobe wanted to engage in price-fixing with Microsoft in order to protect Adobe's quasi-monopoly. That is what you guys are supporting! Do you really want to go down that road? Surely you'll want to rethink your position, or does your hypocrisy really go that far?

3. Microsoft wasn't bastardizing PDF. What would be the point, since Microsoft is not producing any PDF reader? Since Microsoft isn't creating their own reader, any PDF document producted by Microsoft Office would have to be readable by other readers (and printable by printers), so why bastardize the format? Think logically.

4. If you want to see an example of the PDF produced by Office 2007, try Office 2007 beta 2. Or you can read the PDF version of the latest draft of the OpenXML ECMA spec, a PDF document that was created by Office 2007 beta. Guess what, it's perfectly readable by Acrobat Reader and any other PDF compliant reader.

5. Regarding XPS, XPS is a PDF competitor based on XML, but includes many advances over the current PDF spec (though future PDF specs may add such advances). XPS is part of Vista; XPS's role in Vista is similar to PDF's role in Mac OS X. Microsoft has shared with Adobe info on XPS for several years. Now Microsoft, bending over backwards to allay Adobe's hypocritcal paranoia, is removing from Office 2007 built-in support for both PDF and XPS. Furthermore, Microsoft is leaving it up to OEMs as to whether they want to include XPS support in Vista itself (except for XPS's role as a spool file format for Vista's printing enhacements).

6. Lastly, Microsoft is still going to provide PDF and XPS export support in Office 2007 as free downloadable plug-ins. Adobe's still pissed about this because they want Microsoft to charge for the plug-ins (more of the price-fixing scheme that you guys are supporting).

See these links for sources of the above info:
http://blogs.msdn.com/andy_simonds/archive/2006/06 /02/XPSAdobe.aspx
http://blogs.msdn.com/brian_jones/archive/2006/06/ 02/613702.aspx
http://blogs.msdn.com/brian_jones/archive/2006/06/ 03/616022.aspx

Lastly, please don't you (or the state of MA) ever refer to PDF as "open" in the future. If it's not open for all, then it's not truly open, period.

How much do you want to bet Microsoft flatly refused to bind themselves to writing .pdf's readable by code implementing only Adobe's spec?

Microsoft PM Brian Jones wrote about this:

You'll see that we really are trying to comply with the spec, and wouldn't have anything to gain by doing otherwise. Remember we are only a producer of this stuff (not a consumer), and doing anything non-compliant would just mean that our output would be flawed and not look right. That would of course undermine all the work we've done to build this support in the first place... we want people to use it.

Legal issues around PDF support:
http://blogs.msdn.com/brian_jones/archive/2006/06/ 02/613702.aspx

You should read Raymond Chen's blog to get an idea of the completely ridiculous lengths Microsoft has gone, historically, to support backward compatibility in their operating systems. (To their own detriment, IMO)

All zealotry aside, there are things in Windows that are done very well, and there are things in Windows that completely suck, and the things that suck are almost universally due to some sort of backward compatibility concerns.

Think! Malware authors prey upon the stupid and the careless. Why else would there be so many phishing e-mails to the effect of "Your account with [some bank that doesn't even have a presence in your area] has been compromised; to recover it, enter all your personal details on this page here"?

If you don't believe there are users too stupid to live, much less to use a computer intelligently and competently, try following Raymond Chen's weblog for a while. It's a wonder the man doesn't go on a shooting spree.

Windows doesn't allow LUA users to change the system time. That is not a LUA bug, because changing the system time has security implications with respect to auditing and to the Kerberos protocol.

> Said more correctly, you can't mix and match code within an assembly

Actually, it's possible, but Visual Studio won't let you do it.
http://blogs.msdn.com/junfeng/archive/2005/02/12/3 71683.aspx
http://www.abstractvb.com/code.asp?A=1055

Using .NET (VB or C#) you can now program quality 3D games using Managed DirectX which cuts develop time by a third! If you can program a 3D game in C# then it is sufficient for business tools.

Here is a 3D Real Time Strategy commercial game written entirely in C#:

http://www.exdream.com/games_aw.html

Here is a great thread on C# games...C# will start to dominate in indie development:

http://channel9.msdn.com/ShowPost.aspx?PostID=2085 0

You can't mix and match code within a project, although you can use vb/net libraries fine within c# programs and vice versa.

Said more correctly, you can't mix and match code within an assembly (generic term for "a compiled chunk of code", which could be a library (dll), an executable (exe), or even a separate sandbox within another assembly (.NET's XML serializer generates an assembly on the fly to serialize or deserialize XML, for example)). A "project" in Visual Studio compiles to a single assembly, either dll or exe, while a "solution" (which most people would think of as a "project") encompasses one or more "projects". Each "project" in your solution can be written in whichever language you like (MC++^WC++/CLI, C#, VB.NET, J#, F#, JScript.NET, IronPython, etc). The caveat is that your code must conform to the Common Language Specification (CLS) which is essentially a subset of language features that all .NET languages must implement. Languages are allowed to implement more features than those defined by CLS, but should not implement less. This does provide for some pretty arbitrary restrictions (no unsigned types), and some inclusions that may mean extensions to a language (like method overloading, which didn't exist in VB6). You can usually do what you want without worrying about CLS compliance, but every now and then you will get caught up in an issue where what you want to do in one language won't be accessible by another.

You can't mix and match code within a project, although you can use vb/net libraries fine within c# programs and vice versa.

Said more correctly, you can't mix and match code within an assembly (generic term for "a compiled chunk of code", which could be a library (dll), an executable (exe), or even a separate sandbox within another assembly (.NET's XML serializer generates an assembly on the fly to serialize or deserialize XML, for example)). A "project" in Visual Studio compiles to a single assembly, either dll or exe, while a "solution" (which most people would think of as a "project") encompasses one or more "projects". Each "project" in your solution can be written in whichever language you like (MC++^WC++/CLI, C#, VB.NET, J#, F#, JScript.NET, IronPython, etc). The caveat is that your code must conform to the Common Language Specification (CLS) which is essentially a subset of language features that all .NET languages must implement. Languages are allowed to implement more features than those defined by CLS, but should not implement less. This does provide for some pretty arbitrary restrictions (no unsigned types), and some inclusions that may mean extensions to a language (like method overloading, which didn't exist in VB6). You can usually do what you want without worrying about CLS compliance, but every now and then you will get caught up in an issue where what you want to do in one language won't be accessible by another.

Your information on OpenGL on Vista is quite out of date. While the crippled method you talk of is still possible depending on the drivers, perhaps you should keep up with what is happening in Vista development if you're going to be commenting on it.

From http://blogs.msdn.com/kamvedbrat/archive/2006/02/2 2/537624.aspx:

"Windows Vista ICD's - this is a new path for 3rd party ICD's introduced for Windows Vista that will work in a way that is compatible with desktop composition. Essentially allowing direct access to the GPU for hardware accellaration, but then having the final surface that appears to be the front buffer to the application actually be a shared surface that gets composed by the DWM"

I'd say that's a pretty good compromise (though I suppose we'll how it affects performance when it's finally out).

Nofollow was a hare-brained idea from the start, cooked up over a couple of apparently drunken (or perhaps stoned) nights between developers at Google, Yahoo! and MSN.

Microsoft's goal is to get people to plunk down the money to upgrade to Vista, either by buying Vista or by buying a new computer. Vista-only games help this by providing a carrot to get people to upgrade. However, if somebody's favorite game does not run on Vista, that in effect discourages people from upgrading to Vista. Therefore, it would be moronic for Microsoft to go out of their way to break backwards compatibility.

Of course, that doesn't mean that they might break backwards compatibility; games tend to not be perfectly written and often they rely on sloppy behavior. It just means that Microsoft won't make breaking compatibility an explicit goal.

There have been posts here saying that ODF isn't less efficient than Microsoft's formats, it's just that OO.o is less efficent thatn MS Office.
OO.o is indeed less efficient than MS Office, but the fact is, Microsoft's file formats are more efficient than ODF by design.
I won't even deal with Microsoft's binary format or their previous XML format (which are also both faster than ODF), I'll just deal with ODF vs OpenXML (Office 2007's default format).

First, ODF chose human readability over machine efficiency. This is a mistake in my opinion, because programs are going to be manupulating these documents orders of magnitude more often than a human is going to be eyeballing the XML.

Check out this blog entry from Brian Jones' Open XML blog (Brian Jones is Microsoft's main Open XML guy):
Does [tag] Size Matter?
This blog entry describes the benefits of OpenXML's terse tags vs ODF's verbose tags. The blog entry includes a comparison of OpenXML's representation of the spreadsheet:
1 2 3
4 5 6
OpenXML's representation of that spreadsheet requires ~110 characters, while ODF's requires ~780.
It doesn't take a genious to know which would be more quickly parsable by a machine.
There are many other points made by the blog entry tha I encourage you to read.

Another of Brian Jones' blog entries is here: Design Goals Behind SpreadsheetML [OpenXML's spreadheet format]
Among other things, this blog entry discusses the performance goals of OpenXML's spreadsheet format. Microsoft didn't want a huge peformance hit by going from binary to XML. For spreadsheets, they use things like shared string tables to speed things up. I encourage you to read this blog entry for more details.

OpenXML is "faster" than ODF by design, that's just the way it is.

There have been posts here saying that ODF isn't less efficient than Microsoft's formats, it's just that OO.o is less efficent thatn MS Office.
OO.o is indeed less efficient than MS Office, but the fact is, Microsoft's file formats are more efficient than ODF by design.
I won't even deal with Microsoft's binary format or their previous XML format (which are also both faster than ODF), I'll just deal with ODF vs OpenXML (Office 2007's default format).

First, ODF chose human readability over machine efficiency. This is a mistake in my opinion, because programs are going to be manupulating these documents orders of magnitude more often than a human is going to be eyeballing the XML.

Check out this blog entry from Brian Jones' Open XML blog (Brian Jones is Microsoft's main Open XML guy):
Does [tag] Size Matter?
This blog entry describes the benefits of OpenXML's terse tags vs ODF's verbose tags. The blog entry includes a comparison of OpenXML's representation of the spreadsheet:
1 2 3
4 5 6
OpenXML's representation of that spreadsheet requires ~110 characters, while ODF's requires ~780.
It doesn't take a genious to know which would be more quickly parsable by a machine.
There are many other points made by the blog entry tha I encourage you to read.

Another of Brian Jones' blog entries is here: Design Goals Behind SpreadsheetML [OpenXML's spreadheet format]
Among other things, this blog entry discusses the performance goals of OpenXML's spreadsheet format. Microsoft didn't want a huge peformance hit by going from binary to XML. For spreadsheets, they use things like shared string tables to speed things up. I encourage you to read this blog entry for more details.

OpenXML is "faster" than ODF by design, that's just the way it is.

It is also a spreadsheet. Read this blog from Brian Jones about why this is actually a big deal. Consider a spreadsheet used by a third party test: 7 million xml elements, 9.6 million attributes, 131 MB uncompressed. That is not a trivial file to save, especially when compared to what it takes to save in the standard excel format.

Totally. I mean, those three letters are so icky. *shudder* I'm with you, I also base my decisions on what products I use by whether I imagine I dislike any arbitrary sequences of letters that are in any way associated with the product. Much more logical than deciding on, say, features.

BTW, it used to be for "Least-Privileged User Account". Then for Vista it was reassigned to "Least User Access", and then renamed to "User Account Protection ", and now it's "User Access Control".

You are correct in that conditional formatting existed previously and this is an extension of that. Consider a cell with a percentage value in it. The new features enable a different colour at a given percentage, so sub 20% could be green background, 20-40 orange, and >40, red.

Throw in in-cell bars to represent precentages or icons such as Up, Down, no change, and that's what they mean. It is a simple evolution and one wonders why these weren't there before, but for people that do dashboard type documents, they're going to be a real time saver.

Microsoft have and will continue to cop a lot of flak about the radical change of the user interface, but it was about time, and I think that usage patterns have evolved somewhat. I'm mostly Windows-centric (ducks), but not exclusively so and firmly believe the office suite products have taken a significant leap forward with this iteration. There's a lot of good info on the MS website and channel9.msdn.com is usually full of video from the programming teams.

For Excel (demonstrating some of the new conditional formatting stuff and the new Pivot Table stuff try http://channel9.msdn.com/Showpost.aspx?postid=1778 27)

Hope that helps a bit (though far short of the requested review)

http://blogs.msdn.com/excel/ and search tables (the search isn't working atm, so I can't link you directly). That has several posts on tables.

Why must they change the interface when the old one worked so well?

Office developer Jensen Harris explains in his series Why the New UI? Fascinating read. His blog is also a great source for Office UI discussions.

Why must they change the interface when the old one worked so well?

Office developer Jensen Harris explains in his series Why the New UI? Fascinating read. His blog is also a great source for Office UI discussions.

You know that Microsoft does usability tests, right? They don't just randomly place things (well, they did in Office for a long time, which is why they're fixing that now), and they don't just rip-off other programs like open source projects to. You can bet your ass that if Microsoft is making a change for usability reasons, they have documented, repeatable, scientific evidence that the new version is better.

They have a guy over there who blogs the hell out of the whole office usability thing. Very interesting stuff.

Jensen Harris: An Office User Interface Blog

Making features easier to find/discover is [apparently] one of the biggest benefits. Word has a zillion features, and most people use about 10.

Anyway, I'd recommend the blog as an interesting read for those people interested in user interface design for a product with hunderds of millions of users.

The conditional formatting is of a far better calibre than before - "temperature" gradients, automatic range detection etc. Take a look at this video for a quick tour:

http://channel9.msdn.com/Showpost.aspx?postid=1778 27

For an example of the reason Microsoft *should* restrict their employee's (especially development/useability staff), look at the following exchange: Me: It was not a question. If an application requests access far in excess of what it needs, is denied and continues on without problem, the request for access is by definition a LUA bug (it did not need the authorization in able to proceed). If, for example, my application never reads or writes to COM1 but attempts to open it for read/write access, the least I should be guilty of is sloppy coding. However, if I am writing a trojan masquerading as an otherwise useful utility, I would do this to see if I was able to do so. Possible responses: Request denied: Continue with what the user wanted me to do. Request permitted: Deploy destructive payload, then continue with what the user wanted me to do. This scenario is the same whether the request is a registry write, an update/change of system files (libraries, executables, configuration files) or writing to memory (RAM or DISK). Therefore, by definition, any request for services that are not needed to perform the operation is an LUA Bug Answer: Developer from Microsoft (as a result of my comment to his blog): You can choose to define it that way if you want, but it's not a useful definition, and frankly doesn't make any sense to me. For most people, "bug" implies that the object under consideration does not work as designed/desired. For my purposes, I'll stick with my description as posted here: http://blogs.msdn.com/aaron_margosis/archive/2006/ 02/06/525455.aspx Is there some reason that a "security conscious company" would feel that widespread requests for unneeded access should be permitted? If I came to you and said "I want a key to your house, not because I need it, but because I want it", would you feel comfortable giving me one? Better yet, would you feel comfortable if I went down to the local locksmith asking for a key to 1313 Mockingbird Lane and they gave it to me without any questions??? This is what an employee of Microsoft is describing as working as designed/desired!!!

Probably the most important utility on his site is the MakeMeAdmin script. It's can raise your priviledges for one session (say of CMD.EXE), somewhat like SU. It differs from RunAs in that you retain the non-admin user profile, so file ownership, permissions, home directories etc are set to more useful values than with RunAs.

http://blogs.msdn.com/aaron_margosis/archive/categ ory/5785.aspx

(Btw, I personally prefer "Folder Options->View->Launch folder windows in separate process" to MakeMeAdmin, because I remember that's the only way to properly run Windows Update from Internet Explorer as Admin from non-Admin account)

• nonadmin
• TechNet Webcast: Tips and Tricks to Running Windows with Least Privileg
• Aaron Margosis's Blog

• nonadmin
• TechNet Webcast: Tips and Tricks to Running Windows with Least Privileg
• Aaron Margosis's Blog

Registry permissions can be set using reged32.

Installers are also a problem. Since Windows program like making a mess (i.e. putting DLL files in the system and system32 directories), you usually need to run then as Administrator. The "Run As..." menu item can be used to elevate priviliges for a single program. This appears in context (right-click) menus by default, unless you're in the Control Panel. In that case, hold down shift when right-clicking.

Windows Explorer can be started as a different user, if you set the option to run Explorer Windows in a separate thread. This option needs to be turned on for the user you're changing to, not for the current user. You can find this option in Control Panel (Classic View), Folder Options..., View tab, Launch folder windows in a separate process.

Here's a few sources to consult:

• Aaron Morgosis's Blog (non-admin category)
• Using a Least-Privileged User Account
• Applying the Principle of Least Privilege to User Accounts on XP

I'm sure I missed some things, but other posters will point them out.

Runs "The Non-Admin Blog" - one of the most useful resources for this. He's a Microsoft staff consultant, and often has tips for it you won't find elsewhere.

Check it out at http://blogs.msdn.com/aaron_margosis/

Excel 2007 will support spreadsheets with 16,384 columns and 1,048,576 rows. (Source: official Excel blog)

Incidentally, Excel 2007 also raises the memory usage limit from 1 GB to "maximum available memory," which means 64-bit systems will actually let you work with humongous workbooks. If a 2^14-by-2^20 spreadsheet seems like overkill, you've never seen what finance departments can do with Excel. :)

One of the reasons Microsoft moved a lot of functionality into the Kernel between NT 3.5 and NT4.0 was performances (NT being, at its origins a uK based OS).

And I curse them to this day for doing it! NT 3.51 was rock-solid. NT 4 was a piece of crap that crashed all the time. And if you've been following the Vista stuff, they've started moving parts back out of the kernel. From the horse's mouth: http://channel9.msdn.com/ShowPost.aspx?PostID=1488 20

As for the statistics bugs, they are obviously not good. That said, they don't affect very many people, or they would be fixed, because one of the things that the MS Office team does surprisingly well is actually looking at how their apps are actually used in practice. (This may sometimes be a privacy concern, which is another legitimate and interesting thread, but let's not go there now.)

Have a look at the Excel blog and other Office 12 blogs and be surprised at the frequent mentions of "customers" and "users".

Everytime a Firefox article gets posted, I see someone post a hack to fix the memory leak problem. I've tried every one of them and none of them fix it on my end. The only externsion I'm running is Google's Toolbar. Regardless though, no one except the most hardcore Firefox users would ever know to look in about:config to turn off this "feature". And they shouldn't have to either.

> Why does every damn application need to implement its own spell checker?

Which is why Vista's new WPF display subsystem comes with a built-in systemwide spellchecker. This'll work on XP too if you install WPF on XP.

http://blogs.msdn.com/marcelolr/archive/2005/09/21 /472407.aspx

Go ahead, make all sorts of assumptions and develop a bunch of theories. Or look up the facts:

http://blogs.msdn.com/marcelolr/archive/2005/09/21 /472407.aspx

Windows will have standardized spell checking in Vista (and down level on XP).

We have a program like this at Microsoft called Frontline. All of the participants rave about it; it's a great mechanism for those of us in the product groups to figure out how to make our products more supportable and usable, and decrease our customers' need to call Microsoft PSS.

You might say Microsoft's good at tedious, but you have to hand it to them: This time they're really trying something new. Where the other search engines tries to achieve quality and relevance trough variations of link cardinality, anchor text, page rank (how many and how highly valued pages links to a page), etc., Microsoft's trying neural networks and some kind of "artificial intelligence".

So far MSN Search/Windows Live Search is worst of the three big players when it comes to relevance. But they're not too bad, either, and I think there's been a lot of improvement since they launched their beta last year (the beta was incredibly bad). If this "self learning" idea works out, MSN Search very well could become the best engine of them all.

See http://www.searchenginejournal.com/?p=2273 (Search Engine Watch) and http://blogs.msdn.com/msnsearch/archive/2005/10/22 /483846.aspx (Robert Scoble's video inteview with the guys behind the search engine).

I'd also like to point out that relevance is a subjective matter, and sometimes the correct answer to a query might not come from the web index at all. Microsoft already emphasizes answers from Encarta when suitable (Google and Yahoo is doing similar things), as seen in this example: http://search.msn.com/results.aspx?q=what+is+chimp anzee&FORM=QBRE

I think we'll see more similar stuff from MSN Search in the future. Also, Microsoft seems to be the only one interested in experimenting with the search interface on a major service, as can bee seen on their live.com site -- see http://www.live.com/#q=what%20is%20chimpanzee&offs et=1 and the image search http://www.live.com/#q=chimpanzee&scope=images&lod =2&page=results for examples.

(Yahoo also has an interesting interface experiment going on an obscure part of an almost forgotten search engine: http://livesearch.alltheweb.com/)

My point is quite simply that what they're doing may be tedious, but this time they're also trying some fresh ideas.

First up I helped develop a Linux USB webcam driver. These things can sometimes push a serious amount of data about the place and the camera won't wait for you before sending more. Being at the mercy of scheduler because the decoding is in userspace could well mean performance is poor (where I was bayer decoding was done in kernel precisely for speed concerns). The other thing is that if the USB driver is in the kernel the output can be exposed as a video device rather than forcing each program to implement each camera's USB dialect. If you want to use established video playing software this last point is fairly key.

As for stable kernel ABIs... they will only make things worse as fewer people are able to debug your problem. The only people who have the resources to cope with support for a binary driver platform (which are the only winners from a fixed ABI) for hardware with as many permuations as your typical PC are Microsoft (and on Windows people even circumvent measure designed to improve drivers). You need more not fewer people as the amount of hardware possiblities go up and a kernel ABI actively discourages this.

Having to keep even the kernel API stable only encourages resistance to change and layers of glue in the kernel in an attempt to keep old binary drivers working (thus hurting future developments).

As for the space requirements for shipping all those drivers... quite frankly they are negligble compared to the size of disks in your modern desktop computer. Saving even 500Mbytes of hard disk is probably a false economy when your typical disk size goes over 50Gbytes.

Many people have complained about the 32 process limit of Windows CE 5. According to Engadget, Windows CE 6 will support more than 32000 processes, which is indeed an increase of several orders of magnitude.

Win CE is a collection of services that can be used to build a custom embedded OS. Windows Mobile is one of these custom OS's. for more info: http://blogs.msdn.com/mikehall/archive/2005/03/15/ 395958.aspx

I agree about wikipedia. Look at my second response. Here are the links in it:

http://www.groklaw.net/staticpages/index.php?page= 20050331183622861#A4

Legal analysis of the OpenXML lcense scheme. If there have been noticable changes, please note them. Also tell me how microsoft has responded to the specific claims in this analysis.

Brian Jones's Blog

So in the changes is OpenXML GPL compatible? Can you even, from a legal viewpoint, strongly say it is LGPL compatible and how?

I don't want to be spreading FUD, so clarifications are very welcome. Just don't dismiss the facts with a FUD claim.. ;)

You have alot of anger in you. Let's take this calmly one-by-one:

Ok, in who's eyes? From the Open Office people's point of view it is non-discriminatory, but from Microsoft and companies that offer more features it is very discriminatory.

How is it discriminatory in microsoft's eyes exactly? Because it is not their format? Why do they support the wide variety of formats they support in word? (wordperfect, RTF,...) Do they all have the features OpenXML has? Why do they not drop support for these formats. I'm sure wordperfect format was not built with microsoft support in mind.

How about from the user's persepective? I imagine they would say, "Oh, I would love to write this on my TablePC, or I would love to drop in Voice Notes with this letter or include an animation or a video or slideshow, but I have to 'publish' in ODF and it doesn't support any of these features." (Talk about dis-empowering people with software 'constraints')

I thought this was an Open advocacy site, how in the 'fek' do people think that just because they slap 'Open' on the front of something, then 'force' people to use it that this is about openness or empowering people?

I don't get your point. For microsoft to support ODF officialy, microsoft is obligated to make its apps support the 'subset' of features that ODF currently includes in its spec. Nothing more, nothing less. If something is not supported by the ODF spec, no one is saying the user can not use OpenXML. No one is asking microsoft to drop its default file format, just include ODF support. This is what I think most microsoft advocates are missing when they are yelling 'ODF doesn't support this x feature'.

If it was truly non-discriminatory then ODF would look at Microsoft's proposals and work with them instead of trying to TELL Microsoft and OTHER companies how the ODF people think it should be done. They are NOT the sole experts here, PERIOD.

Microsoft is a member of the OASIS consortium. They never chose to become actively involved in it, they just rolled their own. So if it is someone claiming expertise and not cooperating, I think you're pointing at the wrong side.

Open should be truly open, not a just a standard FORCED on the industry with the word OPEN slapped on the front of it.

I could make a new 'open' Image format, call it OpenTNAImage, and then tell the industry that this is the only true 'open' image standard, sell it to some politicians that don't know a pixel from a light bulb. Then tell the rest of the world that they cannot have any say in my 'open standard' format.

Sound good? How about when I tell you that my new OpenTNAImage format is only 256pixels by 500pixels maximum and is only black and white, but HECK, it is OPEN so the entire world should just use it and convert all their images to my 'open' format even if it means the loss of image quaility. As long as I can sell it to non-tech politicians, then it must be the 'best'. Geesh.

How can people truly not get that ODF needs to be truly 'open' and 'extendible'? Not just a standard by people with 'agendas' with the word Open on the front of it?

Well, you might want to read a legal analysis of the OpenXML licensing scheme. Technical merit is dandy and all, but in the business world, legal risk in competing applications with OpenXML support is not going to fly. I would love for you or anyone else to explain how microsoft has addressed the specific legal concerns in Marbux's analysis. This has nothing to do with technical merit, but legal bullshit that businesses pay attention to. This is why competitors cannot just adopt OpenXML. What about Brian Jones saying it is GPL incompatible. And it's not only the GPL applications that are being excluded a

Bullshit. There is no such animal.