Nothing of .Net in Longhorn?
turnitover writes "We've been waiting for Longhorn before we really get on the .Net train, but should we bother at all? According to Mary Jo Foley at Microsoft Watch, Longhorn won't be based on .Net at all. Foley, who's usually right on target, calls this MS's 'dirty little secret'." From the article: "We're guessing that Microsoft will maintain that nothing has changed-that no one ever promised that the .Net Framework 2.0 would be the foundation for Longhorn. But developer types we've been chatting with seem to find this update a newsworthy revelation."
from microsoft's official page on preparing for longhorn, i quote: "Preparing for Longhorn - Longhorn builds on existing security and Microsoft .NET Framework knowledge. Use the resources on this page to understand why it is important to adopt these concepts today, and discover how they will apply to Longhorn tomorrow."
...NET framework knowledge"
...NET framework".
the key here is the word knowledge: "longhorn builds on
which could possibly be construed differently than "longhorn builds on
who knows? maybe i'm reading too much into it..
Huh?
Well no. If it is I've made a pretty good living the last 2-3 years building functional web and GUI apps for clients using vaporware.
I'm Rick James with mod points biatch!
Longhorn was first developed with .NET components being used, but the performance was horrible. Microsoft scrapped the entire development tree and went back to the original code base with much higher quality cut-off points for each of the teams if they wanted to re-add their features to the build, and with the rule that NO .NET components could be a part of the default install.
.NET in the default install, plus the incredibly high quality cut-off points for feature adds, means that Longhorn is truly a very unimpressive service pack to XP rather than a revolution or evolution of the operating system line.
One place where this is really annoying is the new Avalon vector graphics system for applications. This will no longer be included in the default install, which means that developers who want to use it in future applications will burden their users with having to stick their Windows CDs in and install the optional Avalon component before the app will work, which of course will discourage developers from using it.
The lack of
I remember when Microsoft was getting us ready for Win95, back in 1993, telling us we were going all-OLE. Programming would mean sending OLE messages among a universe of interoperable COM objects, reusable in any combination we pleased. Then we got Win95, and a COM that didn't do that, and a *lot* of other stuff we needed to do, then COM+, then DCOM, and on and on. And it was never as easy as they'd promised.
These MS technologies are promoted for the sake of promoting Microsoft. Every generation produces something that would be great, but the marketers and engineers are never on the same page. Microsoft succeeds by putting the marketers in charge, but they wind up baiting developers with great tech, then switching us after we're hooked. Maybe the engineers are too busy making all the legacy almost-happened technologies work at all, rather than switching to the new framework that finally sets us free.
--
make install -not war
If I recall correctly, Longhorn promised to be built on top of a new .NET API level called "WinFX".
WinFX itself is a system-level .NET library that provides application programmers with all the functionality you previously had to rely on Win32 API to get (windows messages, message pumpts, etc).
However, the thing to remember about WinFX is that WinFX does not completely replace Win32 API--it only provides a .NET callable-layer that encapsulates the Win32 API.
I would guess that at some later date (x years from now; x==5, x==10, x==100) once the WinFX API is established and becomes the primary API used by windows system-level programming, then the Win32 API underneath may be rewritten in .NET. I don't think this will happen any time in the near term though.
Hey! Stop copying my sig!!! Stop copying my sig!!! Stop copying my sig!!! Stop copying my sig!!!
what I would give to be able to edit my comments on Slashdot.
*Hint* Preview button.
C++ will continue to be the 'crown jewels' of microsoft.
You misspelled C.
You are not a beautiful or unique snowflake -- but you could be if you got off your ass.
Cute, mildly amusing, totally completely .Not true. .Not .Net: Um, it exists so rather it .Is. .Not on time: Eh? It's here now. .Not secure: Care to elaborate with specifics? .Not free: How's that? You don't have a text editor? .Not stable: Blatant lie.
No Comment.
Sun did bind Java to its next flagship OS. "Java Desktop System" (JDS) is an attempt to slowly integrate Java subsystems into a traditional desktop environment. Future versions of the desktop are expected to fully migrate to the Looking Glass Desktop Environment, which is based on the Java3D API.
JDS is currently available as a complete Linux OS, or a Desktop option for Solaris Sparc/x86/AMD64.
Oh, and BTW: Sun has been integrating Java with Solaris for a very long time. Previous versions of Solaris had many of the CDE components done in Java, including the volume control, media player, and administrative interface.
Javascript + Nintendo DSi = DSiCade
Nope, I have, except that logic dictates that code that constantly executes under a VM will be slower than code that is JIT compiled and then runs as native code.
All major Java JVMs do JIT compilation, and then run the result as native code. Even better, most of them (especially Sun's) do run-time execution analysis prior to JIT compilation so that when they compile to native they can make better optimization decisions than a static compiler or "normal" JIT compiler can do.
.NET has no advantage over Java in this respect. I'd expect Java to have the advantage, actually, given the maturity of its JVMs.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
So? PostgreSQL can run Perl stored procedures. Does this mean PostgreSQL is written in Perl? Does the fact that MS SQL Server finally happens to run a CLR interpreter mean that MS SQL Server is written in C#?
Rich.
libguestfs - tools for accessing and modifying virtual machine disk images
Now, just like Java, .NET programming removes a whole lot of things from the programmers hands, which certainly makes for fewer mistakes (strongly typed, memory management, etc) but does force developers to leave the .NET framework and use (for instance) C++ to write a device driver (coming full circle on why an OS using only .NET isn't currently possible)
Java uses a virtual machine, .NET uses a CLR (not quite as virtual, more an API on a machine), so I think if you wanted to come up with a one liner for .NET, you should come up with one for Java and then simply append the words "... in order to take over the world."
This comment is guaranteed*
*not guaranteed
OK, here is the best I can do with the .NET strategy question while keeping it concise ;-)
.NET is the name they gave it. Besides such an abstract statement, you can look at SOA and XML web-services. Again, these aren't technologies unique to MS but they are examples of the implementation of the .NET strategy.
.NET? Thats a good question ;-) Many will say .NET is just marketing, and its very true that naming it .NET was marketing. However, .NET is not JUST marketing. The name is marketing, but the underlying strategy and goals are very real (and you can see plenty of implementations today).
.NET Framework. The .NET framework is more than JUST making SOA/web service stuff easier (they really needed to update thier stuff anyway so did that as part of .NET Framework). The .NET Framework does do a good job of making this type of interoperablity very easy. Next they needed tools to build applications for the .NET Framework. Thus, VS.NET was born. VS.NET is simply a very productive set of tools to allow you to build .NET applications.
.NET Framework was also the CLR/CLI, this allow you to program in basically any .NET langauge (cobol, vb, java, C#, etc, etc, etc). I assume when you talk about "language similar to Java", you mean C#. That is basically an answer MS needed since they REALLY needed a new modern langauge, but hopefully from the above description you can see that C# is just a tiny little spec on top of the whole .NET platform.
.NET is the name MS gave its goal of making interoperable systems very simple so you can easily and seemlessly have multiple systems on any platform all working together. This isn't just a MS goal, but
Now why call this
The other issue was MS didn't really have any way to accomplish this ".NET strategy" when they came up with it. Luckily, I've never had to try SOA or web services with the VS6 family of tools, but I know those who have and said while it is possible, its one of the more painful things to try. So they needed new tools to enable this strategy. Hense, the
As part of the
"reality has a well-known liberal bias" - Steven Colbert
Forget the original marketing push to have everyone buy into the application as a service model. That was a bit grandiose and given MS's stature in the overall development community (monopolies are not our friends), that was hardly going to fly.
.NET is _today_ is a different way of doing application development. It took Microsoft a long time to externalize their own best practices, but they finally realized that they needed to push their Visual Basic audience up a notch into thinking about object-orientation, messaging, services, and overall best practices in architecture.
.NET successful and useful beyond any of the underlying architecture is the IDE. Visual Studio .NET is by far the most useful tool for developing web and windows applications. And in the next version, 2005, it gets even better. A lot better.
.NET's growing market-base.
.NET is just a productive platform for developing web and windows applications, along with enterprise architectures, that were previously locked in the C++ world.
.NET is.
What
There was no way to do that with VB6 and there was no way to make C++ pretty enough to get people to mass-adopt it. Let's face it, you can put lipstick on a pig, but it's still a pig. (No offense to all you C++ geeks, it's just that for writing a screen and a report for the accounting department, C++ is a bit of overkill).
Anyway, the folks at MS were working on some third-generation messaging stuff and also saw the benefits of managed code in the Java world. So they're not stupid and they spend $5 or $6 billion per year on doing new suff. Out of this came the CLI, the CLR, C#, and in parallel, web services.
Now the lights started going off. They knew they had security problems and they also knew that the business world had moved past the point where adhoc VB6 systems were acceptable. The business world was adopting Java because it came with serious thinkers and sound architectures (stable, secure, and fast).
So as MS does, they adapted to the needs of the business world. They pushed their new toys to that end. But the thing that makes
This is why Sun failed to steal the VB6 crowd away from MS. They never understood that if you create a great IDE, developers will come. Eclipse has proven this theory, although too late to damage
In summary,
At the end of the day, I can say that my job is vastly easier now than it was 5 years ago.
That's what
http://chicagodave.wordpress.com
Well, actually, neither comment is quite correct. I actually work in Visual Studio, and believe I have a tiny bit of insight into this :)
.NET, as another poster mentioned. That would be a massive undertaking and a silly use of developer resources when there is already a stable codebase that is well-understood.
Obviously all of Visual Studio hasn't been re-written in
However, where appropriate, new features being added to VS are written entirely using managed code, where it makes sense. My feature area, for example, is entirely written in C#.