Many applications uses Microsoft .NET Framework 3.5 as development platform, and thus requires .NET Framework to be installed beforehand, else the installation will request to download and install .NET Framework from Internet. On offline system without Internet access or online server with slow downloading speed, the requirement to download setup files through web may hit the wall – a no go.
Microsoft initially just provides a minimal size dotnetfx35setup.exe download which is a bootstrapper that will still need to download more files via Internet. For users who prefer to perform offline installation or install .NET Framework 3.5 SP1 without waiting for download to complete will have to download and save a copy of full complete standalone or redistributable Microsoft .NET Framework 3.5 SP1 setup installer, which is finally published by Microsoft.
Microsoft .NET Framework 3.5 SP1 (Service Pack 1) is a full cumulative update that contains many new features building incrementally upon .NET Framework 2.0, 3.0, 3.5, and includes cumulative servicing updates to the .NET Framework 2.0 and .NET Framework 3.0 subcomponents. See KB951847 for list of changes and fixed issues in the .NET Framework 3.5 Service Pack 1.
Download full package of Microsoft .NET Framework 3.5 SP1: dotnetfx35.exe (231 MB)
For known issues and release notes, refer to Microsoft .NET Framework 3.5 SP1 Readme.
Parallel Programming are two words which are not nearly used enough by programmers today. I think this is partially due to the fact that most developers are answerable to management types who simply "want to get the job done". It's also highly susceptible to deadlocks, race conditions and other problems, which are somewhat more avoidable in traditional single-threaded-apartment model applications. The problem is, that we've reached a precipice in CPU architecture where CPUs are scaling out instead of up. In other words, instead of simply working harder and faster, they're working smarter - executing many simultaneous operations.
The only problem with this is that applications need to be programmed to capitalize on this architecture - and making Multi-threaded applications easier is obviously on Microsoft's mind with the announcements of features in the upcoming The .NET Framework 4.0.
One of the main the main features I am looking forward to is the Parallel class to easily thread simple loops. This Parallel class represents a significant advancement in simplistically managing loops. The .Net 4.0 team assures us that "for many common scenarios, it just works, resulting in terrific speedups". A similar technique can be used to write parallel loops over iteration spaces of non-integral objects.
Parallel.For(0, N, i=>
There are also overhauls to the ThreadPool class (which was in dire need of serious attention) and the inclusion of "Tasks" - simple generic types which assist developers in creating native IAsyncResult objects: this means that Task can be used as the core of a Begin/End implementation. They've also really thought about these improvments, with easy and clear ways to cancel parallel operations, as well as a number of great ways to handle Exceptions within parallel blocks.
There are of course other advantages to the 4.0 Framework, but it's the big emphasis on easing MTA (Multi-Threaded Apartment) model application development that's got me excited.
Cross-posted from the Particls blog.
“IE6 is the new Netscape 4. The hacks needed to support IE6 are increasingly viewed as excess freight. Like Netscape 4 in 2000, IE6 is perceived to be holding back the web.”Jeff Zeldman, standards guru
I saw the link to the bring down IE 6 site today via our friends on Twitter and simply had to announce our support for such an initiative. IE6 while once the browser to which all others were bench marked, is now, frankly the bane of an Internet Start up’s existence. It might have been great once, but all good things must come to an end, and for IE6, that time is now.
For Faraday Media, IE6 support has never been a priority, since our users and visitors are overwhelmingly Firefox users, so unofficially, we’d already been on this bandwagon. Today, it’s official.
If you’re chained to IE6 due to some corporate SOE policy, you have my sympathy. If you’re using IE6 voluntarily, then you only have yourself to blame (just for you, here is the link to Firefox).
I really encourage other start-ups to stand-up and vocally (and officially) join the movement.
Recently I've been doing a lot of work with the Process.GetCurrentProcess() method and since the application I am building is being developed on the 2.0 64bit framework, I was worried that if I used Process.GetCurrentProcess().WorkingSet64, that the application wouldnt work with 32bit OS's, since WorkingSet was deprecated, but not enforced.
After some thought though, I realised that the WorkingSet returns the amount of memory being used by the process as an integer (32 bit signed integer). OK, so the maximum value of an integer is 2,147,483,647 -- which is remarkably close to the total amount of memory that a process can have in its working set. Except, there is actually a switch in Windows that will allow a process to use 3 gig of memory instead of 2 gig. So what would happen when you poll the WorkingSet you will get a negative number, a really big small negative number. Usually, in the realm of -2,147,482,342. As the more perceptive of you have guessed the problem already. The overflow bit.
So you ask, why didn't Microsoft just change the API so WorkingSet returned an Int64 instead of an Int32. Well they could, except that they would break applications built against version 1.0 and 1.1 frameworks, as this post explains.
But after all this pondering, it turns out that WorkingSet64 des exactly what WorkingSet does, except returns an Int64 instead - and as such is less prone to breaks. Works with both 32bit and 64bit Windows and Frameworks and all is good with the world.
Cross-posted from the Particls blog.
For those of you like me who are too stubborn too busy to move to Gmail; our worse nightmares have been realised. Microsoft Outlook (whom consumes approximately ¾ of the corporate world’s email client market) will no longer render HTML emails with Internet Explorer, but instead with the crippled Microsoft Word HTML Engine.
I read David Greiner’s post on the Campaign Monitor Blog, and I agree with his sentiment totally.
After picking up the contents of my desk off the floor and taking a few deep breaths, I tried to come up with a few decent reasons why Microsoft would go in this direction. Here's what I came up with.
Security - But wait! Microsoft have touted Internet Explorer as "a major step forward in security". Surely they'd just replace the IE6 rendering engine with IE7 and be done with it. I'd also love to know how float and position impacts the security of an email in any way.
Consistent rendering - By default Outlook uses the Word engine to create HTML emails, which it's done for years now. Perhaps Microsoft figured that in order to keep the look and feel of emails consistent between Outlook users they'd display emails using the same engine that created them. But what about the millions of other email newsletters out there that aren't created with Outlook or Word? If an email is created with Outlook, then surely it should display perfectly in a modern browser like IE7.
They hate us - OK, this one might be pushing it, but I'm running out of explanations here. Don't get me wrong, we're not Microsoft bashers here. Both our products are developed on Microsoft's .NET platform and we've been a fan of their development environment for the better part of a decade. But seriously, they've taken 5 important years off the email design community in one fell swoop.Without entering the Plain Text/HTML debate, there is simply no sense to Microsoft’s Product design decisions lately. I think we’re starting to see what happens in the IT marketplace when it takes a company too many years to release new versions of their software.
They claim that they are going to start itterating faster yet we have not seen any evidence of this so far.I personally needed Outlook to load faster, use less CPU/Memory and respond far, far faster than it does. I didn’t need its HTML rendering handicapped. Like I said, Microsoft seems to be failing me in areas it used to excel.