The next release of the .NET Framework will include both 32- and 64-bit native support. CLR 2 is allready ported to Itanium (and AMD-64). Christopher Brown discusses how developers writing managed code today will be able to easily port and, in many cases, just copy existing applications to this new environment. The video requires Windows and MS Media Player.
Actually Microsft is being rather smart about this. Longhorn is going to be radically different than previous versions of Windows and while there will be some backwards compatibility, Microsoft wants to puch developers to use the newer technology so they can kill off a lot of the old crap floating around. By getting developers working on .Net and focusing on what’s next the transition to Longhorn will go a lot smoother and there will be a lot more apps and services ready when it launches.
Will I still be able to run 16 bit windows 3.11 apps on 64 bit longhorn? I hope not.
That guy said that the Quake2 demo was being played over a terminal services session. They must have a really nice LAN there because RDP is good, but I’ve never seen it nearly THAT good over even a LAN link. Impressive!
I’m pretty sure that 32-bit Longhorn won’t even support 16-bit apps.
At the time Sun was developping java, lots of different cpus with different instruction sets were around (in the workstation market). Right now, with Itanium and x86-64 Mircrosoft faces a similar problem Sun was facing back then, and the .net runtime will help Microsoft (and any other developers using it) keep costs down, as they won’t have to port their software to different (hardware) platforms.
Of course 32-bit longhorn will support 16 bit apps. Microsoft has said that Longhorn will be the most compatible version of windows to date. Meaning they are going to beef up their 16-bit subsystems. I would think that 64-bit editions of longhorn will also have a 32-bit subsystem layer that will allow 32-bit apps to run as well. Time will tell.
MSDN TV…. what’s the TV stand for? I swear that I kept looking for references to MSN TV (WebTV).
I would assume that they would take the Virtual PC software and have those sorts of apps run in there rather than bogging down the system with legacy support.
Really seems like the only logical solution as to why Microsoft bought Virtual PC in the first place… except to maybe have an end-to-end solution for running Windows software on the Mac (provide the OS, provide the VM software).
Having a VM is great, but if your application is portable how can you lock down user to MS only OSes ?
If i was MS shareholder i would not be happy of seeing the .net framework pushed !
This stuff is IMGO a nonsense, you need portability ? Java is already there ! You need to make windows application, VS is there
What is the final goal of MS ? Suicide themselves ?!?
I’m going to guess the ‘G’ in IMGO stands for ‘godawful.’ Portability is intended to be for Microsoft based operating systems. If you are expecting it to run on Linux, supported by Microsoft, you are mistaken and will be disappointed. Managed code has many benefits besides the potential for portability. Dot net is a unified framework that connects the various popular programming languages for Windows application development. They use the same library, have the same functions available.
“Will I still be able to run 16 bit windows 3.11 apps on 64 bit longhorn? I hope not”
What a stupid thing to want, and even dumber to say!
Why would you want to limit what you can do on your computer?! Please, enlighten me!
It stands for portability
– across programming languages (doing thier wrappers around VB were very time ocnsuming and expensive. Now they only manage one ‘wrapper’ wround the actual C apis)
– across architectures, currently 32/64 bit, but also think about xbox, wince and such
– across versions of windows (there was a problem with some apps wanting to use some api from windows 2k, like the translucency that was added, annd couldnt use it in win98) with dotnet thier is supposed to be an easier way to deal with this, but I dont know what…
I would doubt that 64-bit longhorn will run 16-bit apps. The 64-bit version of WinXP does not even run 16-bit apps unless there is a way to turn it on. I ran into this the other day when trying to run an install that used an old 16-bit bootstrapper. It gave some crypt kind of error message and refused to run the EXE.
It does of course have a 32-bit layer, which on AMD64 is pretty snappy in the BETA that I had loaded up for a while. I was testing our VB6-based product to see how compatible it was (which ran without problem).