By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,030 Members | 986 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,030 IT Pros & Developers. It's quick & easy.

Future of Native Apps?

P: n/a
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.

--
Greg McPherran
www.McPherran.com
Jan 20 '06 #1
Share this Question
Share on Google+
14 Replies


P: n/a
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>
"Greg" <gm@mcpherran.com> wrote in message
news:58**********************************@microsof t.com...
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.

--
Greg McPherran
www.McPherran.com

Jan 20 '06 #2

P: n/a
> 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.
Jan 20 '06 #3

P: n/a
Jim

"Lloyd Dupont" <net.galador@ld> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
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
Jan 20 '06 #4

P: n/a
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)...

--
Patrice

"Greg" <gm@mcpherran.com> a écrit dans le message de
news:58**********************************@microsof t.com...
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.
--
Greg McPherran
www.McPherran.com

Jan 20 '06 #5

P: n/a
>> 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.


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!!!
Jan 20 '06 #6

P: n/a
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.

"Jim" <re***@groups.please> wrote in message
news:be***************@bignews2.bellsouth.net...

"Lloyd Dupont" <net.galador@ld> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
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

Jan 20 '06 #7

P: n/a
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.

"Jim" <re***@groups.please> wrote in message
news:be***************@bignews2.bellsouth.net...

"Lloyd Dupont" <net.galador@ld> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
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

Jan 20 '06 #8

P: n/a
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
"Patrice" wrote:
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)...

--
Patrice

"Greg" <gm@mcpherran.com> a écrit dans le message de
news:58**********************************@microsof t.com...
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.

--
Greg McPherran
www.McPherran.com


Jan 20 '06 #9

P: n/a
Jim

"Lloyd Dupont" <net.galador@ld> wrote in message
news:e9*************@TK2MSFTNGP12.phx.gbl...
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.


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
Jan 20 '06 #10

P: n/a
Jim
"frerring " what the hell is that? I meant to type "referring "......

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

Jim

"Jim" <re***@groups.please> wrote in message
news:s%****************@bignews4.bellsouth.net...

"Lloyd Dupont" <net.galador@ld> wrote in message
news:e9*************@TK2MSFTNGP12.phx.gbl...
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.


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

Jan 20 '06 #11

P: n/a
Greg wrote:
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/ .
Jan 20 '06 #12

P: n/a
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?

"Greg" <gm@mcpherran.com> wrote in message
news:D1**********************************@microsof t.com...
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
"Patrice" wrote:
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)...

--
Patrice

"Greg" <gm@mcpherran.com> a écrit dans le message de
news:58**********************************@microsof t.com...
> 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.
>
> --
> Greg McPherran
> www.McPherran.com


Jan 21 '06 #13

P: n/a
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?

"Jim" <re***@groups.please> wrote in message
news:s%****************@bignews4.bellsouth.net...

"Lloyd Dupont" <net.galador@ld> wrote in message
news:e9*************@TK2MSFTNGP12.phx.gbl...
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.


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

Jan 21 '06 #14

P: n/a
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

"Greg" <gm@mcpherran.com> a écrit dans le message de
news:D1**********************************@microsof t.com...
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
"Patrice" wrote:
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)...

--
Patrice

"Greg" <gm@mcpherran.com> a écrit dans le message de
news:58**********************************@microsof t.com...
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.

--
Greg McPherran
www.McPherran.com


Jan 24 '06 #15

This discussion thread is closed

Replies have been disabled for this discussion.