Slashdot Mirror

8.0 is pretty horrible. You have to disable intellisense (by renaming/deleting feacp.dll) to make it usable for C++ programming. http://forums.microsoft.com/MSDN/ShowPost.aspx?Pos tID=132651&SiteID=1

actually thanks to rigorous backwards compatibility, you can be perfectly safe from productivity all the way through Vista.

"Backwards compatibility"? A lot of anti-productivity software is designed for Windows; it's not just a bunch of old DOS software.

Not that UN*X+X11 doesn't compete there.

At least Apple doesn't bundle much in the way of anti-productivity software with OS X - no Solitaire, for example.

I wrote a device driver in C# once, for the Singularity operating system at MSR. It was remarkably pleasant, truth be told.

http://research.microsoft.com/os/singularity/

How are they supposed to support anything other than W3C specs? The W3C publishes their specs; Microsoft does not.

> Or Microsoft could just give away their product for free, like other vendors
> who make products that aren't "good enough" to sell to the public.

Actually... They do give it away for free, along with coding tools:
http://msdn.microsoft.com/vstudio/express/default. aspx

The W3C publishes their specs; Microsoft does not. If they did [emphasis mine], I'm sure the Mozilla folks would be more than happy to implement it. As it stands, they're forced to try and emulate some of IE's bugs and quirks in order to render poorly-written, IE-only pages correctly.

But as I pointed out earlier in the discussion, they generally haven't done this.

He said that if Microsoft published specifications for MS-HTML, MS-CSS, etc, Mozilla might do something about it. Microsoft leaves a lot of things undocumented, so pointing out that Mozilla hasn't been forthcoming with support for these things doesn't contradict what he said.

Historically, their attitude has been that they would support only the "official" (i.e., W3C and such) specs, and would not implement any concessions to IE compatibility.

This is not the case. Their main focus is obviously on standards, and if the standard way of doing something conflicts with the Microsoft way of doing something, they tend to pick the standard way. But Mozilla have implemented plenty of stuff in the name of compatibility with Internet Explorer. Off the top of my head, there's document.all, favicons, two quirks modes and XMLHttpRequest. I'm sure there's more.

For all the bitching some people have been doing in this discussion about MS not documenting anything, they've also been bitching about IE6 has been standing still for years. It's not like there's a moving target to emulate, and the main differences are well enough known that pro web developers use them on auto-pilot these days!

There's a difference between web developers being able to work around issues and browser developers being able to correctly emulate issues. Compare, for example Microsoft's documentation for hasLayout, and its reverse-engineered description. This one facet of rendering has huge implications on layout, yet it remained an undocumented mystery for five years and still hasn't been totally cracked. Or look at Hixie's description of the way Internet Explorer comes with a DOM tree that isn't actually a tree. Or look at Hyatt's description of the "residual style" problem.

Mozilla and other browser developers already spend plenty of time reverse-engineering Internet Explorer. Are you really criticising them for choosing to implement some standards stuff too rather than spending 100% of their time on reverse-engineering Internet Explorer's crazy behaviour?

According to his profile page, he is a "former" vice president. It was updated on June 20th, presumably to reflect the change in his employment status. Not even retiring Co-President Jim's profile page has been updated to reflect his imminent departure.

According to his profile page, he is a "former" vice president. It was updated on June 20th, presumably to reflect the change in his employment status. Not even retiring Co-President Jim's profile page has been updated to reflect his imminent departure.

Taken directly from the script: http://www.microsoft.com/library/errorpages/smarte rror.aspx?404

I found an M$ reference on it here: http://www.microsoft.com/windows/embedded/windowsc e/default.mspx
Quote:
Windows CE is a hard real-time operating system that has been proven to satisfy RTOS requirements by independent industry laboratories.

Assuming this isn't marketting BS, it appears that CE is a legit RTOS.

I do question your knowledge if you claim CE beats RTOS to a living pulp. Do you even know what an RTOS is and what you're arguing about?

Stop making up stuff. The full list of .NET 2.0 breaking changes is available here; at least cite examples from those if you're going to make claims that .NET 2.0 is completely incompatible with 1.0/1.1.

1) "We added 200 new keywords to the language which will nameclash with your code".

C# 2.0 maintains full source compatibility regarding keywords. The new keywords (where, yield, partial) work only under certain contexts, and can still be used as variable names. For example, where and partial work only in class definitions, i.e. public partial class Blah where T : class, and yield can only exist as yield return 4. There is no legal 1.0/1.1 code like that.

2) "We added 400 new classes to the library which will nameclash with your code".

Types you define in your assembly take precedence over those in other assemblies, so there's no compilation issue. If you want to use new classes that clash with yours, you can add a using SubstituteClassName = ClashingClassName and use the new substitute name.

3) "That function/class no longer does what it used to do". 7) "That function/class now takes a different number of parameters". 8) "That function/class is no longer compatible with that other function/class". 9) "We changed that parameter datatype to X".

Look at the breaking changes page and tell me which one of those impacts you severely. All the changes I see are to fix bugs or security issues, or remove extraneous functionality. New signatures are simply added as overloads and the old signature made obsolete where necessary. See next for why obsolete doesn't mean a break change.

4) "That function/class is no longer available". 5) "That function/class has been replaced by X". 6) "That function/class has been renamed to X".

You can find a list of obsolete APIs here. And before you respond with "see!!! all those obsolete APIs break my code!!!", they're all either obscure or unsafe parts of the API, or have been updated to take advantage of new .NET 2.0 constructs. Furthermore, they're merely marked obsolete and will only generate a warning; you can still use them if you choose.

10) "The new tool won't import your projects properly, so you have to recreate them from scratch (with absolute pathnames) (tied to the user login who created them) (and cryptically stored in the registry) (and you can't run the old tool to see what it looked like)".

That is likely a failing on your part. Visual Studio 2002/2003/2005 all generate solutions that reference projects with relative paths. None of that is stored in the registry; hell, I've been uploading my projects to a Subversion repository and working on them from a variety of locations for years without any path problems.

11) "You can only do that with our new brain-dead wizard". 12) "The tool is smarter than you are, do it the tools way".

All the wizards/tools generate .NET code; you can code everything manually if you'd like, including Winforms and ASP.NET. Even the project files are XML, and in .NET 2.0, you can compile everything without even the IDE installed. What examples do you have of stuff that requires a wizard to work?

Stop making up stuff. The full list of .NET 2.0 breaking changes is available here; at least cite examples from those if you're going to make claims that .NET 2.0 is completely incompatible with 1.0/1.1.

1) "We added 200 new keywords to the language which will nameclash with your code".

C# 2.0 maintains full source compatibility regarding keywords. The new keywords (where, yield, partial) work only under certain contexts, and can still be used as variable names. For example, where and partial work only in class definitions, i.e. public partial class Blah where T : class, and yield can only exist as yield return 4. There is no legal 1.0/1.1 code like that.

2) "We added 400 new classes to the library which will nameclash with your code".

Types you define in your assembly take precedence over those in other assemblies, so there's no compilation issue. If you want to use new classes that clash with yours, you can add a using SubstituteClassName = ClashingClassName and use the new substitute name.

3) "That function/class no longer does what it used to do". 7) "That function/class now takes a different number of parameters". 8) "That function/class is no longer compatible with that other function/class". 9) "We changed that parameter datatype to X".

Look at the breaking changes page and tell me which one of those impacts you severely. All the changes I see are to fix bugs or security issues, or remove extraneous functionality. New signatures are simply added as overloads and the old signature made obsolete where necessary. See next for why obsolete doesn't mean a break change.

4) "That function/class is no longer available". 5) "That function/class has been replaced by X". 6) "That function/class has been renamed to X".

You can find a list of obsolete APIs here. And before you respond with "see!!! all those obsolete APIs break my code!!!", they're all either obscure or unsafe parts of the API, or have been updated to take advantage of new .NET 2.0 constructs. Furthermore, they're merely marked obsolete and will only generate a warning; you can still use them if you choose.

10) "The new tool won't import your projects properly, so you have to recreate them from scratch (with absolute pathnames) (tied to the user login who created them) (and cryptically stored in the registry) (and you can't run the old tool to see what it looked like)".

That is likely a failing on your part. Visual Studio 2002/2003/2005 all generate solutions that reference projects with relative paths. None of that is stored in the registry; hell, I've been uploading my projects to a Subversion repository and working on them from a variety of locations for years without any path problems.

11) "You can only do that with our new brain-dead wizard". 12) "The tool is smarter than you are, do it the tools way".

All the wizards/tools generate .NET code; you can code everything manually if you'd like, including Winforms and ASP.NET. Even the project files are XML, and in .NET 2.0, you can compile everything without even the IDE installed. What examples do you have of stuff that requires a wizard to work?

Why would that break their codebase exactly?

Side-by-Side Execution in the .NET Framework

CE does real-time. Not just a marketing ploy. As the AC said (but most people probably won't read) CE is based on a completely **different** kernel than the NT line. Check out windows Embedded which beats RTOS to a living pulp.

Yes, I agree with your point. The funny thing is that actually Windows Indexing Service is website search engine. It was created to allow IIS to have a search feature for websites hosted by IIS including high traffic sites.

http://msdn.microsoft.com/library/default.asp?url= /library/en-us/indexsrv/html/ixintro_03l1.asp

What Apple got that Microsoft missed is that it needed a good interface and lots of promotion. Instead they just made the tech and then didn't have a clue what to do with it except list it as a bullet point.

What Apple got that Microsoft missed is that it needed a good interface and lots of promotion. Instead they just made the tech and then didn't have a clue what to do with it except list it as a bullet point.

Microsoft has a web site for Robotics Studio. There's a free download version.

From reading the available documentation and tutorials, it all seems very primitive, sort of like Lego Mindstorms meets ".NET". You can issue commands to actuators and get events from input devices. That's about all you get in robotics functionality. No sign of the hard stuff, like vision processing, map building, GPS/INS integration, motion planning, forward or reverse kinematics, or any serious robotics stuff.

The target (on the robot) apparently has to run at least Windows Server 2003 with ".NET". That's a lot of baggage for something that does so little. You'd expect that the target would run Windows CE or something, but apparently not.

The whole thing is very event-oriented, like Windows, rather than real-time cycle-oriented, like most real robotics applications. It seems to be an extension of Microsoft Web Services. It even uses SOAP.

Their simulator is so weak it can't even handle something with joints. (They bought into Ageia, the "fast but dumb" approach to physics). That's disappointing for 2006. We were doing better a decade ago, and by now, everybody else serious has joints working. Simulation for robotics has to be considerably better than that for games, and most of the game simulators cheat quite a bit to get the speed up. That kills you in a robot simulator.

For now, Yobotics and Player/Stage remain way ahead.

http://msdn.microsoft.com/robotics/

They're more interested in software and interoperability. You don't want to roll out software and training programs to find out they've been dropped/updated/replaced. You don't want to buy hardware or software add ons for Apples if Apple is going to make them obsolete.

The "support lifecycle" of OS X is the first thing that came to mind when I read the words "IT Roadmap Complaints." Does Apple even have an official support lifecycle policy for OS X?

By glancing at Apple's security updates and system requirements for their current applications, Apple seems to support the current and previous version of OS X but don't guarantee a length of time for support. Support for OS X 10.2 (Jaguar, released August 2002) seemed to end when 10.4 (Tiger) was released in April 2005. Support for 10.3 (Panther, October 2003) will probably end when 10.5 (Leapord) is released. For some Apple apps, like Final Cut Pro 5, only the current version of OS X (10.4) is supported. Other Apple apps (like Quicktime Pro) only support 10.3-10.4.

Someone who buys OS X today (10.4, Tiger) has to assume that security updates will stop when version 10.6 is released (3-4 years from now). After OS X 10.5 is released, the next version of Final Cut Pro might not work with today's OS X. After 10.6, the next Quicktime Pro won't work. At least Photoshop and MS Office work with the last three versions of OS X (10.2-10.4).

Other companies that sell to enterprise customers have official support lifecycle policies. Novell and Microsoft guarantee five years of "general/mainstream" support from the date of the product's general availability. Novell adds two years of "extended support," MS adds five years of "extended support" for "business/pro" products.

get it here

1. You either use the migration tool included with your new mail product, or you write a script to walk through the users and export their data one at a time.

2. Contacts are included in my earlier post example.

3. Calendar items are included in my earlier post. iCal support (kind of) is in Outlook since XP version, but its not implemented very well. Probably your best bet is to use a 3rd party plugin, like this:

http://outlook2ical.sourceforge.net/

Better iCal support is scheduled for Outlook 2007 released later this year, for what thats worth.

4. Actually, a spreadsheet is not the most useful format to export it in. PST file is the most portable, as nearly every other mail product on the planet knows how to import from it.

And I'm not sure what format you're talking about when you say 'plain email files', unless you mean just a text representation of the email. With that you'd have to then write software to parse out the individual fields and import it to another format, and that doesnt really buy you anything compared to PST or CSV, other than an extra step of software to write. But even if you did have that, it still wouldnt help you with calendar, tasks, contacts, etc etc.

5. I cant speak to that, but a lack of good competitive clients to Outlook doesnt mean the information isnt out there.

For example, here is a link to the MAPI SDK which includes the full API:
http://msdn.microsoft.com/library/default.asp?url= /library/en-us/mapi/html/83f1e307-095b-4d27-a3ec-f f4aa22f471a.asp

Heck, there's even information in there about how it maps to X.400 and the wire-level protocol.

After looking through it for a few minutes (first time I've done that in years), its possible that its just very complicated, probably much more complicated than IMAP. So there's a real diminishing level of return on your investment, given that Outlook is free if you own Exchange (so no cost advantage to writing your own client), plus its a mature and well-developed piece of software. Starting your own would put your a decade behind MS on the client. Of course, if you started one in the Outlook 95 time-frame, that wouldnt have been the case.

The programming is important, everything else is secondary. He isn't against doing things as a community and has embraced a Wiki. His comments about it are quite positive. http://msdnwiki.microsoft.com/en-us/mtpswiki/defau lt.aspx

Facts:

Orbit is open source.
Microsoft makes a number of OS's, office suite, a number of servers, development tools that were better 8 years ago than any FOSS IDE TODAY (Visual C++ 6 VS kdevelop, ajunta, etc to name a few).

To be so much outside reality and insulted by some truth you must be a very passionate Linux advocate, or even a contributor to some useless open source projet that doesn't even compile.

You still have to pay Microsoft to write programs for windows unless it's a batch file

I refer you to the Visual Studio Express Editions. Granted, they are limited versions of the real thing, but VS is a great product; MS deserves to make some money off it. Anyhow, don't bitch about developing for Windows; even the express editions are better than most IDEs.

Yes.....

Because no one at Microsoft has ever thought of how to do clustering in Exchange server:

http://www.microsoft.com/technet/prodtechnol/excha nge/guides/E2k3HighAvGuide/99353155-7908-4d44-a609 -48199919f188.mspx?mfr=true

You can scale out an Exchange infrastructure arbitrarily wide at _any point in the stack_. If your bottleneck is in your MTAs, then setup more dedicated MTA boxes. Is the MAPI/RPC front-end bottlenecked, or how about OWA? Well, you can build out layers of servers that do just those.

Need real heavy POP3/IMAP servers? Can build out those too.

Oh and you want geographically dispersed site-to-site replication? Thats well supported too:

http://www.microsoft.com/technet/prodtechnol/excha nge/guides/E2k3DataRepl/bedf62a9-dff7-49a8-bd27-b2 f1c46d5651.mspx?mfr=true

The options are nearly limitless.

Yes.....

Because no one at Microsoft has ever thought of how to do clustering in Exchange server:

http://www.microsoft.com/technet/prodtechnol/excha nge/guides/E2k3HighAvGuide/99353155-7908-4d44-a609 -48199919f188.mspx?mfr=true

You can scale out an Exchange infrastructure arbitrarily wide at _any point in the stack_. If your bottleneck is in your MTAs, then setup more dedicated MTA boxes. Is the MAPI/RPC front-end bottlenecked, or how about OWA? Well, you can build out layers of servers that do just those.

Need real heavy POP3/IMAP servers? Can build out those too.

Oh and you want geographically dispersed site-to-site replication? Thats well supported too:

http://www.microsoft.com/technet/prodtechnol/excha nge/guides/E2k3DataRepl/bedf62a9-dff7-49a8-bd27-b2 f1c46d5651.mspx?mfr=true

The options are nearly limitless.

Groove is now a part of Office 2007

http://www.microsoft.com/office/preview/programs/g roove/highlights.mspx

Putting PST files on the network is a known 'bad thing', and MS specifically tells you not to do it, that its unstable, and they dont support it.

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

I realize that many organizations do it, and it works okay, but you're basically doing something that the software makers are telling you doesnt work real well. You shouldnt be surprised then if it doesnt work real well.

My question then is, if you're having users put PST files on file servers, why not just give them 1GB+ mailboxes on exchange, and consolidate your storage space?

Would simplify the administration (all mail is in one place, instead of two), and eliminate performance issues.

If you were previously using email-only this is a total non-issue (you could always use any number of clients for pop or imap)

Not true. No matter what type of client you use to access a mailbox, it requires a seperate CAL for each user, unless you go the route of device CALs, in which case you'll need a seperate CAL for each piece of hardware, regardless of what type of client is used.

The fact that each CAL inclueds a license to use Outlook just makes it more attractive for people to use Outlook for their other mailboxes.

Why wouldn't they? A user CAL is linked to the user, not the client software, although each User CAL does come with a license for Outlook. You could purchase a device CAL, and then a machine would be licensed, no matter how many people use it.

Actually, this is exactly the direction that Microsoft seems to be taking with Vista. I just got back from the MS TechEd conference and I was able to talk to some of the folks on the Vista team. They are already doing some nice work with virtualization to keep users from having to run with administrative privileges to make an application work. Add to this the recent announcement (http://www.microsoft.com/presspass/features/2006/ may06/05-22Virtualization.mspx) of Microsoft's intention to acquire a company called Softricity (http://www.softricity.com/) that sells a product that does application virtualization. With Virtual PC and Virtual Server in the mix I'd say that MS might well be on the verge of doing some interesting work.

Anyway, you're missing the point. Yes, people primarily use Outlook to send and receive email. But if you deploy it together with Exchange, you supposedly have a groupware solution. And indeed, the Outlook/Exchange combination is obviously meant to compete with the Notes/Domino combination.

As for Sharepoint, I think you're a little confused as to exactly what it is. Sharepoint is server side software, and it's meant to be used in conjunction with Outlook, not in place of it. Of course Sharepoint has a web interface too — which I guess is what you're thinking about. Which isn't supposed to be the primary interface. Though perhaps folks use it anyway, rather than deal with Outlook's weirdnesses.

Groove was conceived as a P2P alternative the above. Hence my assertion that Groove and Outlook compete.

The new iTunes movie store will have the same hardware requirements as Windows Vista! Wouldn't that be ironic.

When Windows 2000 launched, I was working at Microsoft's technical support. My organization handled all the inbound technical support calls involving Windows 2000. Over the next couple years, I worked at different tech support departments involving SFU, etc. The fact was, it was not that hard to authenticate Windows 2000 against MIT Kerberos. Nor was it that hard to authenticate Linux/UNIX users against Windows 2000's Kerberos implementation using the MIT Kerberos clients. NSSwitch was still an issue that Kerberos was never meant to address, however.

Yes, there were some bugs (for example http://support.microsoft.com/kb/276304/en-us), but for the most part it worked OK.

I closely followed efforts on the part of Microsoft Consulting Services to create interop solutions for customers involving AD integration for Linux hosts. The only real problem here was that although the solution was straightforward, nobody at PSS was willing to support it when something went wrong.

I can remember how excited people on the SFU team were when the MIT Kerberos implementation first allowed one to use SRV records because this made interop quite a bit easier.

The result of many of the earlier efforts have been projects like IDMU, which is quite good actually.

If you review my history, you will see I don't like Microsoft, and I use Linux exclusively, but falsehood need to be addressed.

I do think he will still have a long way to go to shed the more tarnished aspects of his reputation

Problem is, he has a good reputation. I know it's hard to believe, but among those whose opinions mean anything -- i. e. executives, board members, etc. -- his karma is definitely positive. In Sweden, he received an honour doctorate degree (link in Swedish) for his "valuable contributions for IT". I (and everybody else here) know it means nothing, but those who really ought to know, don't.

1) SMB was IBM, but the FS implementation that is being used by MS is an extended version of SMB, and it is called CIFS.

2) I find it hard to believe that people would take time to reverse engineer the MS CIFS protocol considering full specification, documentation, packet information, code samples, and even a free usage license is available from Microsoft directly. (Again an example of 'exactly' what I was talking about, as it is 'open' but not wrapped in a GPL or other standard open source license, but a free usage license instead). - And actually more 'open' than most open source in its source disclosure and usage allowances.

If you still think people had to reverse engineer 'anything' of the CIFS technologies from Microsoft just go here: http://msdn.microsoft.com/library/default.asp?url= /library/en-us/cifs/protocol/smb_header.asp

As you will notice EVERY BIT of information and the license to utilize the CIFS technologies is fully available for free from Microsoft, no reverse engineering required. This information has been available for years and years, and running this technology on non-MS OSes was considered a bit doggy as the original MS Source usage license was for MS only OSes. This is also why MS updated their policy and created a usage license 'specifially' to ensure the usage license also extended to people using this technology on non-MS OSes and non-MS environments.

MS very much supports CIFS technologies in use by projects like SAMBA, or MS would not give a rats butt about Vista potentially breaking them by defaulting to Fast Query.

In a related announcement, Microsoft announced that Raynard D. Fox will be their new Executive Vice-President for Henhouse Security.

How To Annoy Google
===================

Google is running some bot software and a specific kind of database
of links. If you know the alrogithms of these system you can cause
DoS, overload it, and noise it.

Noise: there are some very free content systems. Those who do not
like this freedom fight them by inserting noise (which is allowed because
the systems, are, as we said free). Such incidents are happening on
e-mail, napster forums, etc. Googlebots are sensitive to noise and
we can use this weapon against them.

1) Change your webpage often. Add new words:
How does it work:
Each time google visits a page, it adds it to its index and
then revisits after a couple of days. If the content has not
been modified, the revisit period is extended.
What can you do:
By modifying your page daily with a cron script you force the
google bot to visit more recently. Also you noise the "web-history"
which google collects (but does not provide as a service yet).

2) Add peculiar words and unknown words.
That will mess up googles categories. Google may show off as
something that finds 145,512,388,412 results in 0.023 seconds
but in reallity google is using caches. You can verify that
if you put something that has few search hits: google will
report that there are 8 result pages found, but as you click
`next` you'll only get to page 5. So these numbers are false.

By adding random, irrelevant words, you mess up google's
caching and categorizing server. It will also populate the
link subtables. You can create new words by picking two words
from `/usr/share/dict/words` and joining then. For example
"lifeboatlackey", "treacherysprayer" and "Moonrealign".

3) Run a pseudo-web. If you have the ability to run a server you can
fire up a webserver that generates random content. For example,
download random posts from slashdot, generate page, add link
to new pseudo-web page. That'll teach them!

4) Link to huge content. Download a book from the internet and have a
script that picks paragraphs and makes a new book. Link to this
in text form from your web page. Do this in PDF if you can!

5) Link to random pages. That'll harm google's "who links to whom" service.

6) Link to broken links. That'll make the google bots wander without a cause
and will DoS google's "broken links" database. Make a page with 100000
broken liks: the bots will follow!!

The links should preferrably link to pages with names of words, for example
http://microsoft.com/snoopy/hardware.html
That rises the page-rank.

7) Link to slashdot. Google avoids slashdot!

8) Google words: Google links "words" with "document IDs". Common combinations
of words (like "linux kernel"), form new words. So remember: every time you
search google, please take some time to enter irrelevant words. Google keeps
track of past searches and it sets up a dictionary of "words". But this
system is based on the assumption that people search for interesting things
and it is an "e

It's also noteworthy that Vista requires OEMs to have some kind of networking ability. While this is a given by today's standards, I find it very curious that an operating system REQUIRES me to have it.

The Vista Premium cert ensures that nobody will get complaints like: "Whaddya mean, my brand new PC can't run $ESOTERIC_VISTA_FEATURE_XYZ?!" People may be misled by the submitter's choice of link text. **cough**zonkdoyourjob**cough**

The Vista Premium OEM certification requirements are not the "true minimum requirements for Windows Vista".

The baseline requirements are an 800MHz CPU, 512MB memory, and a DirectX 9-capable video processor. (I think the DX9 requirement is more for driver compliance than hardware features, since GPUs that can't handle Aero Glass will fall back on Aero Basic, and the old Windows 2000 style is still available.) A network connection is not required, and it would be safe to presume that activation by phone will still be available. (And, given the Windows Genuine Advantage mess, that might actually be preferrable to WGA phoning it in for you.)

HOW!?!!?!...Do you get executable code in a SPREADSHEET!?!

MS is not in the ad business

LOL. Of course they are.

I notice you've ducked my direct question about your challenge on Nielsen.

As for the typography thing, perhaps the most obvious recent example is the use of Verdana and Georgia on the web. Both fonts are designed for screen use and then heavily hinted to allow them to display well at the kinds of resolutions used on-screen. In readability studies, Verdana is consistently favoured over Arial by a large margin at the font sizes typically used on web pages.

For some examples of the problems with not hinting fonts, please see The raster tragedy at low resolution at Microsoft Typography.

For display use, anti-aliasing is the best technological answer to this problem in use today, and the sub-pixel anti-aliasing in Microsoft's ClearType technology is very impressive. Even then, though, they still use tools like Visual TrueType to keep the rendering "honest".

The above is most relevant to display on-screen, since they are much lower resolution than printed matter. However, many of the same legibility/readability issues arise in printing, which is why professional-grade fonts often come with several "optical" variations intended for use at different size ranges (typically a "caption" version for 6-8pt, a "regular" version for say 9-13pt, a "subhead" version for 14-24pt, and a "display" version for 25+pt). These have small adjustments that don't change the flavour of the font, but make it easier to read or more visually appealing at the different design sizes. Caption fonts intended for use at smaller point sizes employ many of the same tricks as those designed for screen: slightly larger bowls, for example. The larger fonts tend to tighten up the spacing a touch, to avoid the kind of disconnected appearance you get with a poorly-kerned font at body text sizes, which again is something consistently shown to hurt readability in studies.

So, although I was talking about "hinting", which is primarily a concept relating to screen fonts, the same sorts of ideas apply to printed typography as well. Again, today's automated scaling technologies haven't yet caught up with the fine adjustments a human typographer would make. This isn't to say that it couldn't be done, but right now AFAIK it hasn't been, and if it has, it certainly hasn't entered the mainstream yet.

So, which parts of the above do you think the research contradicts? And which of Nielsen's claims are you going to critique, since you're so keen on specific claims and specific evidence?

I notice you've ducked my direct question about your challenge on Nielsen.

As for the typography thing, perhaps the most obvious recent example is the use of Verdana and Georgia on the web. Both fonts are designed for screen use and then heavily hinted to allow them to display well at the kinds of resolutions used on-screen. In readability studies, Verdana is consistently favoured over Arial by a large margin at the font sizes typically used on web pages.

For some examples of the problems with not hinting fonts, please see The raster tragedy at low resolution at Microsoft Typography.

For display use, anti-aliasing is the best technological answer to this problem in use today, and the sub-pixel anti-aliasing in Microsoft's ClearType technology is very impressive. Even then, though, they still use tools like Visual TrueType to keep the rendering "honest".

The above is most relevant to display on-screen, since they are much lower resolution than printed matter. However, many of the same legibility/readability issues arise in printing, which is why professional-grade fonts often come with several "optical" variations intended for use at different size ranges (typically a "caption" version for 6-8pt, a "regular" version for say 9-13pt, a "subhead" version for 14-24pt, and a "display" version for 25+pt). These have small adjustments that don't change the flavour of the font, but make it easier to read or more visually appealing at the different design sizes. Caption fonts intended for use at smaller point sizes employ many of the same tricks as those designed for screen: slightly larger bowls, for example. The larger fonts tend to tighten up the spacing a touch, to avoid the kind of disconnected appearance you get with a poorly-kerned font at body text sizes, which again is something consistently shown to hurt readability in studies.

So, although I was talking about "hinting", which is primarily a concept relating to screen fonts, the same sorts of ideas apply to printed typography as well. Again, today's automated scaling technologies haven't yet caught up with the fine adjustments a human typographer would make. This isn't to say that it couldn't be done, but right now AFAIK it hasn't been, and if it has, it certainly hasn't entered the mainstream yet.

So, which parts of the above do you think the research contradicts? And which of Nielsen's claims are you going to critique, since you're so keen on specific claims and specific evidence?

I notice you've ducked my direct question about your challenge on Nielsen.

As for the typography thing, perhaps the most obvious recent example is the use of Verdana and Georgia on the web. Both fonts are designed for screen use and then heavily hinted to allow them to display well at the kinds of resolutions used on-screen. In readability studies, Verdana is consistently favoured over Arial by a large margin at the font sizes typically used on web pages.

For some examples of the problems with not hinting fonts, please see The raster tragedy at low resolution at Microsoft Typography.

For display use, anti-aliasing is the best technological answer to this problem in use today, and the sub-pixel anti-aliasing in Microsoft's ClearType technology is very impressive. Even then, though, they still use tools like Visual TrueType to keep the rendering "honest".

The above is most relevant to display on-screen, since they are much lower resolution than printed matter. However, many of the same legibility/readability issues arise in printing, which is why professional-grade fonts often come with several "optical" variations intended for use at different size ranges (typically a "caption" version for 6-8pt, a "regular" version for say 9-13pt, a "subhead" version for 14-24pt, and a "display" version for 25+pt). These have small adjustments that don't change the flavour of the font, but make it easier to read or more visually appealing at the different design sizes. Caption fonts intended for use at smaller point sizes employ many of the same tricks as those designed for screen: slightly larger bowls, for example. The larger fonts tend to tighten up the spacing a touch, to avoid the kind of disconnected appearance you get with a poorly-kerned font at body text sizes, which again is something consistently shown to hurt readability in studies.

So, although I was talking about "hinting", which is primarily a concept relating to screen fonts, the same sorts of ideas apply to printed typography as well. Again, today's automated scaling technologies haven't yet caught up with the fine adjustments a human typographer would make. This isn't to say that it couldn't be done, but right now AFAIK it hasn't been, and if it has, it certainly hasn't entered the mainstream yet.

So, which parts of the above do you think the research contradicts? And which of Nielsen's claims are you going to critique, since you're so keen on specific claims and specific evidence?

Nobody's mentioned the Access Project so I'll talk it up. An Access project (.adp file instead of a .mdb) has most of the features of MS Access (read: quick development), but requires a MS SQL backend. It exposes to the client all the server Procedures and Triggers (and Views) you write. You can even write and save them from within Access. This is a very powerful feature because it allows you to centralize the code on the server and stay away from crappy VB on the client. It's strictly client-server development (no objects or MVC here) but extremely fast for development.

Managers blame the workers
Workers blame the managers

The law seems true, except it doesn't make any sense. Managers aren't allowed to blame the workers. If managers are blaming workers, then they aren't really managers. If I can't hire or fire, then I'm not really a manager, I'm more like a leader. Managers fire workers who are not up to snuff, managers hire competent people to complete projects, managers control quality / quantity of output done by the workers they manage.

Of course, workers correctly blame managers, b/c project success is the manager's responsibility. ;)

Too often they forget they are costs to the programme and have to offer real, obvious, value to be worth having.

Clearly, MS (and other big biz) seem to forget that piece when offering bonuses to management. This manager-based bonus seems pretty flawed in light of the concept that management is actually project overhead. There are two fundamental elements at play here.

1. You're already paying a manager for the sole purpose of completing the project.
2. This manager is supposed to be part of the team delivering the project.

Unfairly rewarding the management ignores both of these facts. A manager successfully guiding a 9-man team does not deserve a $10,000 bonus. He and each of the other team members deserve a $1,000 bonus. A manager's job risk/responsibility is already accounted for with his higher salary, paying him an additional bonus ignores team contribution to the completion of the project.

You get what you pay for. If you pay for managers who complete projects, you may or may not get workers who care. If you pay for teams who complete projects, you will get teams who care.

Rewards must be constructed to encourage desired behaviour.

Any MBA can understand this (was probably taught this), but actual practice of this is difficult. It raises too many issues of accountability that most humans simply don't like to face.

If I want to encourage desired behaviour, I now have to identify desired behaviours, then I have to list these behaviours, I have to communicate them in the form of goals... Eventually it gets around to having vision statements on everything I do: company visions, project visions, employee career path visions... And that's all just more work and planning than most people like to do. Plus all of that planning and visioning not only produces nothing (shareholders hate this :), it also makes people accountable for what is produced.

So back to MS, this is where the breakdown has occurred (other posters have mentioned this other ways). The MS vision appears to be "We want to be the Operating System to the world". Clearly the scope of the vision is too grand and MS has spread themselves too thin. So now, very little will get done as too many hands are working in undirected fashion trying to figure out what it means to be "OS to the world". Is it OS? Office? Dev tools? Web activities? Media? Server software?

They don't really have "too many chefs making their own meals" all with the vision of making their software "Interoperable by Design". Notice how that vision didn't include any real goals? So guess what you get? Software built without any real goals! (exactly what you paid for)

if you don't trust their black hats, try it yourself
download the beta
install
hack

I did notice that part of their security was deprecating the C API and creating a "secure" one with the same names but _ first (at least VC 2005 now gripes about the C API). Not sure what the difference is, but I've heard the new API does checking on the buffers for over/underflow.

my biggest grudge against Microsoft, however, is their shoddy OGL support and floating DirectX API. DX7-8 cool new features and faster, but you have to relearn the API. DX8-9 - cool new features and faster, but you have to relearn the API. DX9-10 cool new ... aw screw it. I tried to keep a codebase of compatible OGL/DirectX code for 2 years before going all OGL.

The Unix Haters Handbook is available for free, in PDF format.

From a guy who works for Microsoft, of course.

The time lag is largely due to only having an IE team that fixes bugs. They now have a full time team, and according to the MSDN blogs, it looks like the team is to stay even after 7 ships. Also, they have a developer toolbar for IE now, too, although it isn't quite as powerful as Firefox's yet: http://www.microsoft.com/downloads/details.aspx?Fa milyID=e59c3964-672d-4511-bb3e-2d5e1db91038&displa ylang=en From what I've seen with IE7, when it does crash, it is a much cleaner crash than Firefox. I can't count the number of times that Firefox has crashed (that's fine, I expect software to malfunction once in a while) and it takes 3-4 minutes even through task manager to exit it when it hangs. At least with IE7 it closes almost immediately.