Actually WinFX is not "the next iteration of the.NET BCL" either. WinFX is a set of Windows specific APIs built on top of.NET 2.0 runtime and framework. In other words, there will be no new runtime or framework for Vista. WinFX itself is really three sets of APIs rolled under one umbrella:
Windows Presentation Foundsation (WPF) - provides scalable vector 2d, 3d, rich documents, etc... the "blinking lights" as they say
Windows Communication Foundation (WCF) - provides communication support for SOAP and WS-* specs, P2P, supports pluggable protocols/wire formats
Windows Workflow Foundation (WWF) - provides support for creating workflows (used by Office12 for example).
It's also important to note that WinFX is not tied to Vista either. There are different set of APIs within the WinFX umbrella that are going to be available on 2003 and XPSP2 as well. Most likely (perhaps obviously) however, the v1 release of WinFX for all platforms will coincide with Vista's release.
I'd say you made a mistake, not so much in quitting, but rather for the reason you quit. Making a statement like Microsoft's tools take away from your ability to develop is just silly and shows that you made no effort to understand what options you had within the environment.
As for Visual Studio, assuming you're company is truly forcing you to use it, the answer to total control is simple: Don't use the designers. Every single source file (for forms, components, HTML, etc.) is editable via pure text and the IDE will not do a damn thing to it in that form. There's no magic. Don't like the designer? Don't use it, just use the text editor and you're fine.
Also, unless your company is truly forcing you to use Visual Studio, there's nothing inherent to.NET development that forces you to use it. Microsoft has gone to great lengths to make sure the SDK contains 100% of what you need to to build full fledged.NET applications with nothing but notepad.
So unless you really just don't want to do.NET development then quitting based soley on that reason was probably a mistake.
Hmmm... sounds a lot like Microsoft's Avalon API + Longhorn's (well, it used to be in Longhorn, not sure after cuts) desktop compositing engine which basically uses Avalon to render the entire desktop. If you've seen the Aero user interface examples, you know what I'm talking about.
IE has searchable history. Not only can you free text search it, but you can also have it organized by date, by site visited, order visited today, etc.
Cg is to vertex shader assembly as C++ is to x86 assembly.
It's a proprietary high-level language, sure, but the assembly code it emits is 100% standard and will run on any GPU that supports DirectX 8.x and up.
Some JVM implementations generate the same sort of stub for their runtimes. So technically if you consider this a hack, it just as much a JVM hack (depending on the implementation of course!) as it is a CLR hack.
In fact... it's basically a hack for any PE, no matter what it's contents, which Win32 executes blindly.
This virus takes advantage of the fact that the PE for CLR executable assemblies includes a small stub to bootstrap itself into older platforms that do not recognize and or honor.NET PEs natively (i.e. older versions of Windows).
This is really not part of.NET or the CLR, but rather a MS specific "optimization" that saves them from having to retrofit CLR PE recognition into their older platforms when the CLR is RTM. For more information, check out this thread[1] on the Developmentor.NET mailing list.
The important thing to point out is that this hack does not foil CLR security. It's foiling standard Win32 security and only because of the afforementioned "optimization".
Slashdot Mirror
Actually WinFX is not "the next iteration of the .NET BCL" either. WinFX is a set of Windows specific APIs built on top of .NET 2.0 runtime and framework. In other words, there will be no new runtime or framework for Vista. WinFX itself is really three sets of APIs rolled under one umbrella:
It's also important to note that WinFX is not tied to Vista either. There are different set of APIs within the WinFX umbrella that are going to be available on 2003 and XPSP2 as well. Most likely (perhaps obviously) however, the v1 release of WinFX for all platforms will coincide with Vista's release.
I'd say you made a mistake, not so much in quitting, but rather for the reason you quit. Making a statement like Microsoft's tools take away from your ability to develop is just silly and shows that you made no effort to understand what options you had within the environment.
.NET development that forces you to use it. Microsoft has gone to great lengths to make sure the SDK contains 100% of what you need to to build full fledged .NET applications with nothing but notepad.
.NET development then quitting based soley on that reason was probably a mistake.
As for Visual Studio, assuming you're company is truly forcing you to use it, the answer to total control is simple: Don't use the designers. Every single source file (for forms, components, HTML, etc.) is editable via pure text and the IDE will not do a damn thing to it in that form. There's no magic. Don't like the designer? Don't use it, just use the text editor and you're fine.
Also, unless your company is truly forcing you to use Visual Studio, there's nothing inherent to
So unless you really just don't want to do
Hmmm... sounds a lot like Microsoft's Avalon API + Longhorn's (well, it used to be in Longhorn, not sure after cuts) desktop compositing engine which basically uses Avalon to render the entire desktop. If you've seen the Aero user interface examples, you know what I'm talking about.
IE has searchable history. Not only can you free text search it, but you can also have it organized by date, by site visited, order visited today, etc.
Here's my understanding:
Cg is to vertex shader assembly as C++ is to x86 assembly.
It's a proprietary high-level language, sure, but the assembly code it emits is 100% standard and will run on any GPU that supports DirectX 8.x and up.
Some JVM implementations generate the same sort of stub for their runtimes. So technically if you consider this a hack, it just as much a JVM hack (depending on the implementation of course!) as it is a CLR hack.
In fact... it's basically a hack for any PE, no matter what it's contents, which Win32 executes blindly.
This virus takes advantage of the fact that the PE for CLR executable assemblies includes a small stub to bootstrap itself into older platforms that do not recognize and or honor .NET PEs natively (i.e. older versions of Windows).
.NET or the CLR, but rather a MS specific "optimization" that saves them from having to retrofit CLR PE recognition into their older platforms when the CLR is RTM. For more information, check out this thread[1] on the Developmentor .NET mailing list.
0 107B&L=DOTNET&D=0&P=47726
This is really not part of
The important thing to point out is that this hack does not foil CLR security. It's foiling standard Win32 security and only because of the afforementioned "optimization".
Later,
Drew
[1] http://discuss.develop.com/archives/wa.exe?A2=ind