Slashdot Mirror

Additionally, it appears that they have adopted a covenant not to sue:

Here are a few more specific and detailed questions and answers about Microsoft's 'Covenant Not to Sue' approach:

There is no longer really a license that people need to sign up for in any way--No one needs to sign anything or even reference anything. Anyone is free to use the formats as they wish and do not need to make any mention or reference to Microsoft. Anyone can use or implement these formats to both read and write the formats with their technology, code, solution, etc.

Patents--We eliminated the license to patents language and are instead providing an irrevocable commitment to not sue anyone based on the patents we have in the formats. If any parties prefer, we will make available the existing open and royalty free license as an alternative.

Why does Microsoft have patents in this case at all?--We pursue patents early in our development process (as required by law) to protect our innovations and protect ourselves at the same time. Having patents gives us the ability to fend off patent lawsuits that are the inevitable result of being a big company and delivering new technology. In this case we are deciding not to enforce our patents in connection with these formats.

Transferability of solutions and "GPL Compatibility"--If someone wants to build a solution that works with our formats, they are free to do so without worrying about patents or licenses associated with our formats. The concerns raised with our previous license about attribution and sub-licensing are now eliminated. Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can't give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but we believe we have removed the principal objections that people found with our prior license in a very simple and clear way.

Subsets, supersets, and 'conformance'--Anyone is free to work with a subset of the specifications, and anyone is free to create extensions to the specifications. A 'conformant' use is simply one that does not modify the specification. Of course subsets and supersets may create incompatibilities with other uses of the specifications and we want to provide some guidance on this topic in the future, but this will be guidance and not a mandate. The key is that this is an assurance that no one will be sued for using intellectual property in the specifications as they are written.

Source: http://www.microsoft.com/office/preview/developers /ecmafaq.mspx#EXB

Last year on Channel 9 we had the pleasure of seeing a brief interview with Bill Gates and during it hinted at a $500 tablet.

See a clip of this comment and explanation here.

Last year on Channel 9 we had the pleasure of seeing a brief interview with Bill Gates and during it hinted at a $500 tablet.

See a clip of this comment and explanation here.

if (window.XMLHttpRequest){
 
// If IE7, Mozilla, Safari, etc: Use native object
          var xmlHttp = new XMLHttpRequest()
 
}
else
{
if (window.ActiveXObject){
 
// ...otherwise, use the ActiveX control for IE5.x and IE6
          var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
          }
 
}

if (window.XMLHttpRequest){
 
// If IE7, Mozilla, Safari, etc: Use native object
          var xmlHttp = new XMLHttpRequest()
 
}
else
{
if (window.ActiveXObject){
 
// ...otherwise, use the ActiveX control for IE5.x and IE6
          var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
          }
 
}

if (window.XMLHttpRequest){
 
// If IE7, Mozilla, Safari, etc: Use native object
          var xmlHttp = new XMLHttpRequest()
 
}
else
{
if (window.ActiveXObject){
 
// ...otherwise, use the ActiveX control for IE5.x and IE6
          var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
          }
 
}

OpenOffice.org is enormous. I have the Mac version of OpenOffice.org 2.0 and it's 341.5 MB large. NeoOffice/J, the "more Mac-like" version, exceeds 500 MB in size. Both take forever to start and look hideous, even more so than Microsoft Office for Mac.

Where did you get the 70 MB figure from -- the installer? Once you actually unpack and install OpenOffice.org, it rivals Microsoft Office for raw bloat. Its Excel clone is absolutely awful, barely playing catch-up to Excel's worksheet storage limits (which are about to increase again) and saving Excel files in formats so arcane even GPLed Excel readers can't parse them. OpenOffice.org doesn't support importing Excel files with automation or third-party add-ins.

Microsoft Word is not the killer app for MS Office. Excel is way up there, and Outlook is too. I don't like it any more than the next Linux user, but there isn't a free product out there that provides all the features long-time Outlook users have come to demand. I blame the Linux zealots who scoff condescendingly on the Outlook-using masses.

Because if any one of the questions had been by any person ever asked to design a site it would have included something like the following:

Well no, seeing as they've already fixed everything you mention: PNG, position: fixed, native XMLHttpRequest. Have you tried the latest beta?

Oh and line 1 and 3 are only there to keep IE happy. 2nd line would be all that is needed if you coded only for real browsers.

Nonsense. Those lines are there to not break for any browsers that don't support native XMLHttpRequest objects. That includes quite a few versions of quite a few browsers.

No doubt IE7 will cause this simple code to expand yet more.

Internet Explorer 7 includes a native XMLHttpRequest object so it acts exactly like all the other browsers and you don't need the extra code that Internet Explorer 6 and below does.

Because if any one of the questions had been by any person ever asked to design a site it would have included something like the following:

Well no, seeing as they've already fixed everything you mention: PNG, position: fixed, native XMLHttpRequest. Have you tried the latest beta?

Oh and line 1 and 3 are only there to keep IE happy. 2nd line would be all that is needed if you coded only for real browsers.

Nonsense. Those lines are there to not break for any browsers that don't support native XMLHttpRequest objects. That includes quite a few versions of quite a few browsers.

No doubt IE7 will cause this simple code to expand yet more.

Internet Explorer 7 includes a native XMLHttpRequest object so it acts exactly like all the other browsers and you don't need the extra code that Internet Explorer 6 and below does.

Because if any one of the questions had been by any person ever asked to design a site it would have included something like the following:

Well no, seeing as they've already fixed everything you mention: PNG, position: fixed, native XMLHttpRequest. Have you tried the latest beta?

Oh and line 1 and 3 are only there to keep IE happy. 2nd line would be all that is needed if you coded only for real browsers.

Nonsense. Those lines are there to not break for any browsers that don't support native XMLHttpRequest objects. That includes quite a few versions of quite a few browsers.

No doubt IE7 will cause this simple code to expand yet more.

Internet Explorer 7 includes a native XMLHttpRequest object so it acts exactly like all the other browsers and you don't need the extra code that Internet Explorer 6 and below does.

There are several excellent reasons for even "Average Joes" to upgrade from 98 and XP. I _thought_ the article was going to highlight improvements like Kernel upgrades, Network Stack and IPv6, and Memory Management with the fluff stuff but was sorely disappointed.

I was pretty ambivalent about up upgrading until I watched these interviews. Of course, given the source I take what they say with a grain of salt. On the other hand, these guys are the coders and not the businessmen, so I think I'm more willing to listen to them when they say they're onto something cool.

Dang it, there I go trusting something M$ has to say...another marketing victim ;)

There are several excellent reasons for even "Average Joes" to upgrade from 98 and XP. I _thought_ the article was going to highlight improvements like Kernel upgrades, Network Stack and IPv6, and Memory Management with the fluff stuff but was sorely disappointed.

I was pretty ambivalent about up upgrading until I watched these interviews. Of course, given the source I take what they say with a grain of salt. On the other hand, these guys are the coders and not the businessmen, so I think I'm more willing to listen to them when they say they're onto something cool.

Dang it, there I go trusting something M$ has to say...another marketing victim ;)

There are several excellent reasons for even "Average Joes" to upgrade from 98 and XP. I _thought_ the article was going to highlight improvements like Kernel upgrades, Network Stack and IPv6, and Memory Management with the fluff stuff but was sorely disappointed.

I was pretty ambivalent about up upgrading until I watched these interviews. Of course, given the source I take what they say with a grain of salt. On the other hand, these guys are the coders and not the businessmen, so I think I'm more willing to listen to them when they say they're onto something cool.

Dang it, there I go trusting something M$ has to say...another marketing victim ;)

You may want to take a look at this blog http://blogs.msdn.com/msnsearch/archive/2006/01/20 /515606.aspx
to read about Microsoft's reluctant handing over of the search records. User information was scrubbed out, leaving a list of queries with a count of how often they occurred as well as a random set of indexed pages. What this means is that if you searched for "my name is jim smith and I live at XYZ and would like to see child pornography" that maybe you could be concerned. If you queried for "sex with children", your query will be counted as +1 with the 128 other people who searched for that term on day Z. If you searched for your social security number, telephone number etc... the government may have a record of that now...oohhhh scary.

microsoft: http://blogs.msdn.com/msnsearch/archive/2006/01/20 /515606.aspx cannot find the AOL thing in orginal, but the same statement given on several websites for example: http://www.computerworld.co.nz/news.nsf/news/7597E 58808CE8391CC2570FE0026880E

Not just that - but Office SharePoint 2007 includes Excel Services so that you can work with spreadsheet from your browser
see http://blogs.msdn.com/excel/archive/2005/11/08/490 502.aspx

A little off-topic, but take a look at:

http://blogs.msdn.com/jensenh/archive/2006/02/17/5 34099.aspx

It's a blog from one of the UI guys working on the new Office 12. It sounds like they're addressing all your concerns in the next version, and I'm pretty excited about it myself.

yet....

The new Office is called "2007 Microsoft Office System." It was first announced to the public on Jensen Harris' blog (he is one of the architects of the new UI). The official Microsoft announcement for the press can be read here. I don't like it much, but it looks like they use the old car manufacturer naming scheme. Does this mean that we can expect a 2008 Microsoft Visual Studio?

GeoTrust sells low assurance SSL certificates. The only thing they validate is that you "control" the domain (which usually means that they just send you "confirmation" email to whois address. Anyone with stolen credit card can register a domain, and get the certificate, while staying untracable.

Most other CA sell High Assurance certificates, that require validation of
entity ownership of the domain
the fact that person ordering ssl for the domain has the right to do so.
This is done via checking bunch of details, such as departement of state database, whois record, company records, etc, etc, etc. You have to be officer of the company or have notirized permission from the officer of the company to request ssl certificate for the domain. The whois record for the domain must match details from the state database.
When taken all thouse checks together - it alows to prevent fraudster in most cases (you cannot prevent them all the time, not in real time).

GeoTrust "pioneered" low assurance certificates (and basically destroyed credibility of padlock), that bypass all thouse checks and go after domain control only. It created this mess. The "give away" that certificate is low assurance is that "Organization" field of the certificate holds domain name instead of company name. No real bank would go for that.
This is one of the reasons opera displays the company from the certificate field right next to the URL.
This is also the reason microsoft plans to differentiate between "high assurance" and "low assurance" certificates
http://blogs.msdn.com/ie/archive/2005/11/21/495507 .aspx

Here's the way it was described in the big anti-phishing browser summit with Microsoft, Mozilla, Opera, and KDE:
http://blogs.msdn.com/ie/archive/2005/11/21/495507 .aspx

The idea at the time was for red to indicate known phishing sites, yellow to indicate suspected phishing sites, and green to indicate a site that was both secure and trusted (though they hadn't worked out the criteria for a trusted site at the time). Normal SSL sites would show the lock, business name, and CA, but would have an ordinary white background.

Presumably a phishing site with SSL would either be red with the lock or just red (since the lock and business name show up in the same place as the shield and "Phishing site!"). This is conjecture, though, because I'm not willing to point my copy of IE at a known phishing site just to see what it does!

And I know which one exactly is going to really shine :)

Raymond Chen seems pretty smart to me.

http://blogs.msdn.com/oldnewthing/

C++/CLI does not have multiple inheritance

It does, but there are places where you cannot use it because the CLR does not have multiple inheritance. The information is kinda fuzzy on this subject... You will find places that say that MI isn't supported, but they mean for things exported to the CLR.

it does have generics, which are templates without the metaprogramming possibilities -- because it does not have templates.

Why C++/CLI Supports both Templates for CLI Types and the CLI Generic Mechanism

Henceforth, the STL does not work under C++/CLI. Nor does Boost.

That's a different matter, as implementations often need to use compiler-specific tricks.

NGEN makes sense for some assemblies. Doing NGEN for an app which is relatively small and easy to compile compared to the common library assemblies is not always a big win, and the actual size of the compiled image on disk can easily be bigger than the MSIL. Add that to special checks that can result in NGEN being skipped in some situations, and it's not always a clear win. Don't forget all the metadata overhead still has to be kept in the assembly, so it's just a question of MSIL vs x86 in the actual method code (and inlined code). This isn't always a vital area for perf, as the JIT is pretty good.

That doesn't mean NGEN isn't a win, but it's often not nearly as dramatic as people first assume, and sometimes it's a net loss.

The real issue with .Net bloat isn't native compilation (in most cases). The biggest culprit is often simply memory usage (.Net apps tend to have a lot of allocations, and people reference and use lots of libraries). See http://blogs.msdn.com/ricom for some great tips.

For the second, realise that .Net perf is generally great for long-running processes (better than native in some ways, due to less leaks) and is not so hot on startup. The gist is that you don't want to pay the CLR runtime overhead very often; if you can start up a process with the CLR in it, and keep it running you're much better off than in running/exiting/running/exiting. This is true of any app that has a large runtime library to some extent, which is why apps like MS Office always tries to keep part of itself running in memory, and it's not even using .Net.

This blog has a lot of information about debugging .Net using windbg. The focus is mainly ASP.Net applications but many issues, like memory usage and deadlock, would carry over to any server code.

A common example is when an application saves its runtime settings to a registry key under HKEY_LOCAL_MACHINE (which is read-only to LUA users), instead of to HKEY_CURRENT_USER.

Considering the bias and errors, it's hardly "informative".

I assume that by:

Digital Research's product, DRDOS had features that were clearly superior to the competitors. Most notably, DRDOS 6.0 was not bound by 640k ram limit that hobbled MSDOS.

You're talking about the ability to load parts of the DOS kernel, along with drivers into the Upper Memory Area. This actually happened with DR-DOS 5, in 1990. MS-DOS followed afterwards in mid-1991 (and the delay - coupled with the disaster that was DOS 4.0, cost them badly).

Following on, your comments about Windows 3.1 completely ignores that a) the non-MSDOS detection in Windows 3.x (note: not a specific test for DR-DOS, but a test for a non-MS-DOS) was only in a beta and never in any shipping versions; and b) the test itself had perfectly valid technical reasons for existing.

You also ignore that DRDOS had incompatibilities, particularly with games utilising the additional memory available via the HIMEM.SYS and EMM386.EXE memory managers present in later versions of DOS, or that were otherwise highly optimised under the assumption they would be running under MS-DOS.

Moving on to Novell:

Microsoft used this power to steal the word processing market, and this is how: they closely guarded their APIs until Windows 95 was released, and they shipped Word for Windows on the same day. It took Novell months to perfect a Windows 95 version of WordPerfect, and in that time they lost their market share.

Even ignoring how silly the idea of an *OS vendor* withholding *developer information* from *developers* is, the idea that Word 95 could somehow wipe out the market share of a decade's worth of entrenched WP users in a matter of months is not only flat-out ludicrous, but would be stunningly high praise of Word as a product if it had actually happened.

Wordperfect had been in decline for _years_ before Windows 95 - mainly because their early Windows products sucked massively - and since they were basically just DOS versions wrapped in a GUI layer, they took little to no advantage of the facilities Windows had to offer, like printing, truetype fonts, WYSIWYG and the like. As a consequence, anyone that wasn't already a hardcore WP user wasn't interested, because Word was easier to use, printed to any printer with Windows drivers and could give a good representation of what the printed output would look like on paper, while you were working on the document. Added to that, many WP users _were_ interested, because not only did Word offer significant advantages, but Microsoft went out of their way to make transitioning from WP to Word very easy, with full support for Wordperfect's file formats and keyboard controls. Back then, there was basically an option box that turned Word into a better looking, more functional version of WordPerfect (it's been a very long time, but IIRC it actually asked the user during install to choose between "Word or Wordperfect" compatibility).

Fundamentally, WP made the same mistake Lotus did - they ignored Windows as a "fad" or "toy" and barrelled on with their DOS-based products. Microsoft, OTOH, with years of experience from writing software for MacOS, were able to provide _good_ Windows/GUI-based apps that more people found attractive. Coupled with their intense desire to knock WP off its perch, and the lengths they went to to make the Wordperfect -> Word transition easy, it's probably the best example of Microsoft winning a market 100% on merit. You can read a more firsthand account here (I personally only have the perspective of a consumer from that era).

Your Internet Explorer comments ignore that a) the biggest period of growth Internet Explorer had was in the 6-odd months between IE4 being released for Windows 95 and Windows 98 being rele

A few months ago, the IE team asked web developers to switch from using CSS hacks (which depend on additional bugs which may not get fixed at the same time as the ones you're working around) to using Conditional Comments, which let you target specific versions of IE using intended functionality rather than bug side effects.

This still requires effort on the part of web developers, but they at least tried to get the ball rolling back in October.

It can also be mitigated by checking for capabilities rather than browsers. For example, look for a DOM function, and if you don't find it, look for the IE function, instead of the other way around. It's the way they recommended handling AJAX when they announced the native (i.e. non-ActiveX) implementation of XMLHTTPRequest.

if (has standard function) {
do standards-based stuff for Firefox, Opera, Safari, IE7, etc.
}
else if (has IE function) {
do IE-specific stuff
}
else {
do fallback stuff for primitive browsers
}

From looking at my own sites, half the bugs have been the result of CSS hacks I'd forgotten about, and the other half have been attributed to a particular bug in the new beta/preview/whatever: Horizontal padding is applied incorrectly on absolutely positioned elements, causing the text to overflow the right edge of the box. I put together a testcase and reproted it on the IE blog, where I found that at least 2 other people had reported the same bug.

Does everything need to be officially announced to qualify as an "immediate comment" Blogging seems to be good enough for many other companies. A reply was posted in the IE blog (which IE 7 b2 Preview even adds links to when installed): http://blogs.msdn.com/ie/archive/2006/02/01/522682 .aspx.

Fairly official response (taken from another comment).

We received reports this morning that a security researcher had found a bug in the IE7 Beta 2 Preview release. This issue reportedly crashes IE and is exploitable to execute arbitrary code on the user's computer. Naturally, we take the security of IE and our users' safety very seriously, so we investigated immediately. We did confirm that the bug crashes IE. However, we did not find that the bug was exploitable by default to elevate privilege and run arbitrary code.

This bug had already been found during our code review and analysis that is a mandatory part of our development process; it was scheduled to be fixed before our next public release. We do not believe this bug is easily exploitable, and as an extra defense, the /GS flag also catches the overrun. This is a compiler flag that tells Windows to watch for some classes of buffer overflows. If Windows sees a problem, it kills the application, in this case IE, instead of running the exploit code. While this is certainly not our primary line of protection, it does offer defense-in-depth to help keep our customers secure.

So it appears that Microsoft's new development practices caught this bug internally before it was caught in the public beta, to find bugs like this. It also seems that the overrun is caught and dealt with (causing a crash as overruns should, but not allowing any degree of "control") by the system they are using for development anyway. Apparently the original article has not proven that the bug could be exploited at all yet anyway, so a response from his end will be required before this can really be seen as anything other than the sort of thing that's to be expected from a beta release.

Did you even bother to read the IE Blog? of course not, it's much better just to slam Microsoft, because you don't like em...

else you would have seen: http://blogs.msdn.com/ie/

Which just so happens to mention:

We received reports this morning that a security researcher had found a bug in the IE7 Beta 2 Preview release. This issue reportedly crashes IE and is exploitable to execute arbitrary code on the user's computer. Naturally, we take the security of IE and our users' safety very seriously, so we investigated immediately. We did confirm that the bug crashes IE. However, we did not find that the bug was exploitable by default to elevate privilege and run arbitrary code.

This bug had already been found during our code review and analysis that is a mandatory part of our development process; it was scheduled to be fixed before our next public release. We do not believe this bug is easily exploitable, and as an extra defense, the /GS flag also catches the overrun. This is a compiler flag that tells Windows to watch for some classes of buffer overflows. If Windows sees a problem, it kills the application, in this case IE, instead of running the exploit code. While this is certainly not our primary line of protection, it does offer defense-in-depth to help keep our customers secure.

At this time, we are not aware of any active exploits taking advantage of this bug. We will continue to monitor the situation and evaluate our response.

Finally, I'd like to reiterate the importance of the responsible disclosure of security issues. We firmly believe that privately disclosing security issues to software vendors is the best way to keep the users of the world secure. To report a security issue against any Microsoft product, please contact secure@microsoft.com. For other feedback on IE7, please use the methods Jason mentioned yesterday.

- Tony Chor

In that vein, I've seen a lot of comments asking if we will pass the Acid2 browser test published by the Web Standards Project when IE7 ships. I'll go ahead and relieve the suspense by saying we will not pass this test when IE7 ships. The original Acid Test tested only the CSS 1 box model, and actually became part of the W3C CSS1 Test Suite since it was a fairly narrow test - but the Acid 2 Test covers a wide set of functionality and standards, not just from CSS2.1 and HTML 4.01, selected by the authors as a "wish list" of features they'd like to have. It's pointedly not a compliance test (from the Test Guide: "Acid2 does not guarantee conformance with any specification"). As a wish list, it is really important and useful to my team, but it isn't even intended, in my understanding, as our priority list for IE7.

Calling Tom Ferris a "Security Researcher" is like calling Bill Gates a programmer... He is more a 'Robert Scoble' character. And his discovery of arbitrary code execution is incorrect as per the link: http://blogs.msdn.com/ie/archive/2006/02/01/522682 .aspx

The guy is not a professional anything, I mean he lists workarounds as 'Firefox'; which just shows how little he understands the security field which he claims to work in (A workaround should be a way to fix or bypass the bug, not a blind pointer at some random other product, even the Linux Security guys know that).

http://channel9.msdn.com/showpost.aspx?postid=1594 60 has a video of some of the IE development crew talking. The interesting thing was there was a googl hat on the desk of the office he guy was in.

Can I call BS on that? Rhetoric, all of it and I quote from your above post on the MS IE Blog, "I wanted to make it clear that we know Beta 1 makes little progress for web developers in improving our standards support, particularly in our CSS implementation. I feel badly about this, but we have been focused on how to get the most done overall for IE7, so due to our lead time for locking down beta releases and ramping up our team, we could not get a whole lot done in the platform in beta 1. However, I know this will be better in Beta 2 "

I would like to point out that the above post is dated July 29th, 2005.

Half of the problems with IE's implementation of CSS (from a designers POV) is that they insist on sticking us with defaults other than 0, none, or off. As far as they're concerned they're not bugs - they're features.

The comments you pointed out only highlight MS's opinion that the situation with CSS has very low priority. A very low priority indeed.

According to eWeek.com, "Sources claiming familiarity with Microsoft's IE 7.0 plans said the company will add some additional CSS2 support to its new standalone browser. But Microsoft isn't planning to go the whole way and make IE 7.0 fully CSS2 compliant, sources said."

Of course, one site, 465BeraStreet.com can even wag a finger @ MS for fixing bugs at all, "When Internet Explorer 7 is released, probably later this year, it looks like one long-standing CSS selector bug in IE will be fixed: the Star html Selector Bug, also known as the Tan hack. Since the bug has been used by many web developers to target specific CSS rules at Internet Explorer as a way of working around various CSS bugs in the browser, some are worried that Microsoft fixing the bug in IE 7 may cause developers a lot of extra work."

And to highlight my point that M$ just doesn't care at all about CSS standards or compliancy thereof, CNet quotes Greg Sullivan, of the Windows client group as saying, "While it is true that our implementation is not fully, 100 percent W3C-compliant, our development investments are driven by our customer requirements and not necessarily by standards"

If they can't get around to it until after Alpha/Beta releases to fix issues they've known about for years now and because they themselves say that it isn't a priority to even try to meet the standards, No, I don't expect M$ to give any priority to the problems with CSS where I.E. 7.0 is concerned.

The worst, however, as highlighted above, Microsoft's utter lack of response to the issues in the past has now lead to a situation where any action to do anything positive would swamp designers with so much back-peddling to remove all their I.E. 5.5 hacks that new hacks would have to be implemented to cover up old hacks that are covering up old hacks... all because they didn't do anything earlier and still refuse to do anything about it now.

No my friends, CSS and IE will not be reconcicled - not now, not ever. They missed the boat.

IMHO.

Yes, yes and yes.

I appreciate that it's a genuine question, but a completely information-free comment should not be Score: 4, Insightful.

I'm a little surprised. I remember a story several months back saying that IE7 would only work on Vista. Is this just a special build with limited features, or will we see IE7 be backwards compatible?

Internet Explorer 7 will support OpenSearch 1.1, which is an XML document describing how an application can use a search engine.

enabling Cleartype is actually a very good idea. (but it doesnt make much sense for a browser to do this, it should be enabled by default)

there is a quite interesting video (http://channel9.msdn.com/Showpost.aspx?postid=146 749 ) about it. (it basicly says that people can read ClearType text faster and more accurate than standard text

See Novells Complaint from page 44

I'm not sure how far this suit has progressed, but it would appear that at the time Microsoft made specific documentation available to ISVs on a case by case basis depending on how much of a threat the ISV represented to them.

According to the document Microsoft refused to include the specifications for using the windows Dialog Box Manager, a feature that is now fully documented on MSDN and seems to be regarded as ancient history by Windows developer Raymond Chen.

If such a major chunk of functionality was really initially reserved for MS Applications it would seem as though the Novell case couldn't fail to succeed. My guess is that they will end up settleing for some vast payout and the whole issue will disappear.

• Application level audio control
• Application specific remoting
• Vastly improved networking stack (apparently superior to any other OS's)
• Support for user mode drivers
• New printer technology (way beyond postscript)
• Pluggable crypto system

As noted on the IE blog, IE 7 won't support the "application/xml+xhtml" MIME type. That means that all of your XHTML 2.0 documents will still need to be sent as "text/html", and will thus be parsed as HTML. Yay, progress!

Sounds like, when they say "future", they mean "fuuuuuuuuuuture".

"The article is written by the typical wank reporter then who did not do his research. Disabling ActiveX **does not** have anything to do with disabling access to the ActiveX() wrapper in javascript."

My, my.. you did your research better even than the IE developers:

http://blogs.msdn.com/ie/archive/2006/01/23/516393 .aspx

Directly from the developer of the feature: "In IE7, XMLHTTP is now also exposed as a native script object. Users and organizations that choose to disable ActiveX controls can still use XMLHTTP based web applications."

Also if you research a bit further you'll see that not every DLL link means ActiveX object is created.

• Fix this problem: http://support.microsoft.com/default.aspx?scid=kb; en-us;177378 Documenting a design flaw does not make it any less of a design flaw.

They did :)

http://channel9.msdn.com/
And the videos about sparkle:
http://channel9.msdn.com/showpost.aspx?postid=1153 87
http://channel9.msdn.com/Showpost.aspx?postid=1578 43

http://channel9.msdn.com/
And the videos about sparkle:
http://channel9.msdn.com/showpost.aspx?postid=1153 87
http://channel9.msdn.com/Showpost.aspx?postid=1578 43

http://channel9.msdn.com/
And the videos about sparkle:
http://channel9.msdn.com/showpost.aspx?postid=1153 87
http://channel9.msdn.com/Showpost.aspx?postid=1578 43

http://blogs.msdn.com/ie/archive/2005/09/13/465338 .aspx

Announced back in September!

Here's a list of what they were anticipating having for beta 2:

• HTML 4.01 ABBR tag
• Improved (though not yet perfect) <object> fallback
• CSS 2.1 Selector support (child, adjacent, attribute, first-child etc.)
• CSS 2.1 Fixed positioning
• Alpha channel in PNG images
• Fix :hover on all elements
• Background-attachment: fixed on all elements not just body

Plus a bunch of bug fixes. I can think of things I could do with every single one of these, and while I'd like more (say, max-width and min-width, or generated content) it's a big improvement. Maybe IE 8.0?