Future of Native Apps?

[Guest]

Is it possible that in some future version of Windows, only .NET (CLR) PE
(Portable Executables) .exe will be enabled to run. I.e. the OS will not
support running of native x86 code .exes/dlls?

I understand native is needed for drivers etc. but at some point the driver
spec may even require MSIL and MSIL will add instructions to support drivers.

 

[Lloyd Dupont]

I don't think so.
All the industry, including microsoft, is very keen on backward
compatibility.

Think of it this way: you could upgrade to the latest Windows 2023 (Formerly
know as Vista Reloaded), but your favorite old DOS games you play in the
90ies still work...
And if it doesn't you sure will get customer complaints!....

--
Regards,
Lloyd Dupont

NovaMind development team
NovaMind Software
Mind Mapping Software
<www.nova-mind.com>

 

[Guest]

I don't think so.

All the industry, including microsoft, is very keen on backward
compatibility.

I don't think so. Look at VB. All VB source code for native development from
the past can now only be built for .NET with recent versions of Visual Studio.

 

[Jim]

I don't think so.
All the industry, including microsoft, is very keen on backward
compatibility.

Please, sir.....do not partake of the wine before posting.

Think of it this way: you could upgrade to the latest Windows 2023
(Formerly know as Vista Reloaded), but your favorite old DOS games you
play in the 90ies still work...
And if it doesn't you sure will get customer complaints!....

A Microsoft rep had pity on me once and told me that unless enough people
complain about a problem it won;t even be addressed at Microsoft.

I hope those games remain popular for you - and don't cut into XBox sales.

Jim

 

[Patrice]

No, it would likely make no sense as "native" code is the only thing the
processor understands. Historically programming is adding layers between the
processor and the developer but ultimately your code still have to reach the
processor under a suitable form ; you can generally "enter" at any level you
want ("debug.exe" is always part of XP)...

 

[Lloyd Dupont]

I don't think so.

I don't think so. Look at VB. All VB source code for native development
from
the past can now only be built for .NET with recent versions of Visual
Studio.

I don't understand what you're saying at all.
Are you telling me that: "Microsoft is not keen on backward technology
because latest technology need latest compiler to be compiled"?

There is no logical relation between the first part of the sentence and the
second I could see!!!

 

[Lloyd Dupont]

Allright, let's say only Microsft then is keen on backward compatibility.

To all the doom sayers and rumor mongers who spread rumor to the contrary I
reply that no software that I have kept since 1995 and like enough to still
use today has any problem to run.
Which includes:
- death rally DOS Game
- OpenStep development environment
- debug.exe 16bit assembly compiler
- Orion95 game
- Master of Magic (an other 1995 game)
- Corel Draw 3
- Word97
- gcc 2.95

I have yet to see these "famous backward incompatibility" that Microsoft is
supposed to be good at. So far I had ample proof of the contrary.

 

[Lloyd Dupont]

After reflection. to be fair, I have WinXP.
It's true that backward compatibility was not paramount with WinNT & Win2000
But XP is more recent that NT or 2000, so I think it's a moot point.

 

[Guest]

You are missing my point. Windows could cease to provide access to the CPU.
Try accessing the CPU on a video game system for example.

Windows may simply take away all utilities and .exe formats that access the
CPU directly. Yes, you could always boot into another OS, but Windows itself
could be set up to not allow access to the CPU.
--
Greg McPherran
www.McPherran.com

No, it would likely make no sense as "native" code is the only thing the
processor understands. Historically programming is adding layers between the
processor and the developer but ultimately your code still have to reach the
processor under a suitable form ; you can generally "enter" at any level you
want ("debug.exe" is always part of XP)...

 

[Jim]

I don't understand what you're saying at all.
Are you telling me that: "Microsoft is not keen on backward technology
because latest technology need latest compiler to be compiled"?

What the poster is frerring to is the fact that most Visual Basic 6
applications must be completely re-written to be used in the VB.Net
compiler. Microsoft intentionaly broke backwards compatability with Visual
Basic 6 source code when they designed VB.Net.

They abandoned millions of VB programmers and billions of lines of code with
a single stab in the back.

There is no logical relation between the first part of the sentence and
the second I could see!!!

I hope this had made it clearer for you.

Jim

 

[Jim]

"frerring " what the hell is that? I meant to type "referring "......

(Note to self: Spell-check should remain on.)

Jim

 

[Marcus Cuda]

Is it possible that in some future version of Windows, only .NET (CLR) PE
(Portable Executables) .exe will be enabled to run. I.e. the OS will not
support running of native x86 code .exes/dlls?

I understand native is needed for drivers etc. but at some point the driver
spec may even require MSIL and MSIL will add instructions to support drivers.

If you haven't seen it, check out MS research project Singularity -
http://research.microsoft.com/os/singularity/ .

 

[Lloyd Dupont]

Take it like that:
"Microsoft just release his new DotNetOnly Powered Windows Next Generation,
this new OS support great support for .NET apps (a specification which means
nothing to the end user) and break security barrier by Not Running Anymore
all previously build execuitable"

Now: who want to build such an OS where all his/her previous investment in
software is broken?

You are missing my point. Windows could cease to provide access to the
CPU.
Try accessing the CPU on a video game system for example.

Windows may simply take away all utilities and .exe formats that access
the
CPU directly. Yes, you could always boot into another OS, but Windows
itself
could be set up to not allow access to the CPU.

 

[Lloyd Dupont]

Allright..
I see...
That does not mean: "breaking bakcward compatibility" at all.
In fact you could keep using VB6 for the year to come and produce VB.exe the
way you're used to.
That means they just have stop supporting/bothering about classic VB.

There will be no new development in classic VB and, i f they had added VB
support in VS2003/2005 that would have been the exact same IDE (because they
won't bother), so why not just stick to VS6?

 

[Patrice]

I believe I understood what you meant. What I meant more precisely is that
IMO it would make non sense to spend time and efforts to "lock up" something
that is native to a processor on a computer.

IMO the problem is not the same for video game systems. They essentially
sold you a low cost powerfull PC to get your money on a long run by solding
games. If those PCs were "unlocked", you could bought them a PC without
buying games (i.e. they would sold you a PC at a low price and they couldn't
get money later as you wouldn't have to buy games for this machine).

So IMO you can be quite confident that you won't see this during your
lifetime.

--
Patrice

You are missing my point. Windows could cease to provide access to the CPU.
Try accessing the CPU on a video game system for example.

Windows may simply take away all utilities and .exe formats that access the
CPU directly. Yes, you could always boot into another OS, but Windows itself
could be set up to not allow access to the CPU.