Win32/64 Running as Emulation Layer on .NET in Future
Dennis Landi
My on-going quest to make sense of this technology upheaval...
I have seen many posts in the passed several weeks stating that
a) Win32/64 will run as a emulation layer on LongHorn, and that
b) The native LongHorn api will be .NET.
Can some knowledgeable person provide authoritative links to either of these
statements?
Thanks.
-dennis
Eric Grange
They won't provide you links, because
a) it's the opposit, Win32/64 are the only non-emulated layers
in LongHorn (the engine itself is a CPU virtualization framework,
ie. an emulator for a virtual CPU that speaks MSIL).
b) .NET is all about being NOT native, but replace "native" with
"preferred" in the sentence, and that's ok.
Eric
Frank Andreas de Groot
news:3fd8978c$1...@newsgroups.borland.com...
>
> Can some knowledgeable person provide authoritative links to either of these
> statements?
Interesting discussion about this here:
http://www.osnews.com/comment.php?news_id=5019
(with a prevailing notion that .net will be wrapped around Win32 but MS can
"hide" Win32 at will)
Dennis Landi
That's what I was looking for:
<quote>
In short, Longhorn is the .NET version of Windows which finalizes the
replacement of the WIN32 API with a managed system, as well as a massive
rethink as to the way developers write applications for Windows and
consumers interact with their computers.
.NET, .NET and more .NET
A year ago, I wrote a three part series (part 1, part 2 and part 3) where I
argued that one of the reasons .NET would conquer the world was that
Microsoft would convert its entire product library into .NET applications.
Well, based on the PDC roadmap, it turns out I was right, so ha, ha, ha, ha.
(Pay no attention to that, it's my jetlagged alter-ego talking.)
Longhorn will be the first operating system where ALL functionality is
designed to be accessed through managed code. WIN32's reign as the Windows
API has ended, replaced by managed .NET APIs.
In short, Longhorn is the .NET version of Windows which finalizes the
replacement of the WIN32 API with a managed system, as well as a massive
rethink as to the way developers write applications for Windows and
consumers interact with their computers.
.NET, .NET and more .NET
A year ago, I wrote a three part series (part 1, part 2 and part 3) where I
argued that one of the reasons .NET would conquer the world was that
Microsoft would convert its entire product library into .NET applications.
Well, based on the PDC roadmap, it turns out I was right, so ha, ha, ha, ha.
(Pay no attention to that, it's my jetlagged alter-ego talking.)
Longhorn will be the first operating system where ALL functionality is
designed to be accessed through managed code. WIN32's reign as the Windows
API has ended, replaced by managed .NET APIs.
</quote>
Gospel? Wiggle room? Who will gainsay that?
Craig Stuntz [TeamB]
> > I have seen many posts in the passed several weeks stating that
>
> They won't provide you links, because
Neither do you, FWIW. I haven't seen anything definitive on this, and
it wouldn't surprise me if the truth is somewhere in between (some
things one way, some things the other way).
-Craig
--
Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH
Delphi/InterBase Weblog : http://delphi.weblogs.com
InterBase in Multi-tier World -- Use multiple RDMs, IB features in
your appserver: http://delphi.weblogs.com/stories/storyReader$195
Alessandro Federici
> Can some knowledgeable person provide authoritative links to either of
these
> statements?
What about the Longhorn SDK? There might be something in it.
Check http://longhorn.msdn.microsoft.com
Joanna Carter (TeamB)
<everything twice>
Wow, that's some jet lag!! your second copy caught up and still got here in
time to beat the first one :-)
Joanna
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
Eric Grange
http://msdn.microsoft.com/netframework/using/understanding/netframework/default.aspx
The shows and wording are pretty clear, I don't see how anyone
could come to infer that .net was going to be native or emulate
native APIs after reading them, since they explicitly state the
opposit.
Eric
Hrvoje Brozovic
> b) The native LongHorn api will be .NET.
> Can some knowledgeable person provide authoritative links to either of
these
> statements?
As someone with 20 years in programming,
I know that this is pure nonsense by default.
But, hearing it so many times,
and from respectable people,
I really wondered about it for a few weeks.
Even started similar thread NET is the OS rumble.
with question
"Any links to info how a hell are
they going to make NET OS"
And, surelly, no link then, as there is no now.
As every sane person knows for himself,
but this MS marketing mumbo jumbo make
you suspect you own common sense.
Atmapuri
> As every sane person knows for himself,
> but this MS marketing mumbo jumbo make
> you suspect you own common sense.
Amen!
Atmapuri
Craig Stuntz [TeamB]
> Here is one for you: "Understanding the .net framework"
>
> http://msdn.microsoft.com/netframework/using/understanding/netframewor
> k/default.aspx
When I click this link I see a table of contents with no comment on
your assertion one way or the other.
I see a lot of assertions on this subject and little hard
documentation. It may well be the case that plans for Longhorn are
still being finalized and even Microsoft isn't positive at this point.
-Craig
--
Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH
Delphi/InterBase Weblog : http://delphi.weblogs.com
Everything You Need to Know About InterBase Character Sets:
http://delphi.weblogs.com/stories/storyReader$306
Dennis Landi
news:3fd9...@newsgroups.borland.com...
???
Which wording where Eric? Quotes please. Explicitly state where?
Oliver Townshend
> > b) The native LongHorn api will be .NET.
> > Can some knowledgeable person provide authoritative links to either of
> these
> > statements?
> As someone with 20 years in programming,
> I know that this is pure nonsense by default.
Well I have 26 years in programming and I can't see why it's nonsense. You
obviously never used a Dec Alpha running NT, which essentially emulated
Win32 and Win16. If .Net is a portable environment, then the same
considerations will apply.
Oliver Townshend
Frank Andreas de Groot
news:3fda...@newsgroups.borland.com...
> > As someone with 20 years in programming,
> > I know that this is pure nonsense by default.
>
> Well I have 26 years in programming and I can't see why it's nonsense.
OK, I admit I have a mere 23 years, but when I read that some really believed
that .net would become "native OS", I was flabbergasted. You need to
misunderstand about 10 fundamental concepts, not all of which of technical
nature.
It's like declaring that microcode would be implemented in BASIC.
Mike Swaim
> Well I have 26 years in programming and I can't see why it's
> nonsense. You obviously never used a Dec Alpha running NT, which
> essentially emulated Win32 and Win16. If .Net is a portable
> environment, then the same considerations will apply.
It was more like HotSpot. The FX emulator would rewrite commonly used code
as Alpha machine code. After 3 or 4 runs (or a single run that had executed
for a decent amount of time), almost all of the code that was commonly
executed was running natively. (The translation was also persisted across
runs and machine reboots.)
What concerns me is that with the current crop of CPUs, a lot of work is
done by the CPU to make sure that instructions execute quickly. They do a
number of tricks to increase performance of the code that they execute,
which makes the JITter's life easier. Intel's EPIC architecture makes the
reverse assumption. The CPU does pretty much nothing internally to optimize
execution, and it relies entirely on the compiler to make sure that its
pipeline stays full. (And each VLIW contains 3 instructions, so the analysis
is more complicated, too.) I have yet to see anything saying that MS has
solved this problem.
(Of course, this might just mean that we'll all be running Athelon and
Yamhill processers 3 years from now.)
--
Mike Swaim sw...@hal-pc.org at home
mps...@mdanderson.org or msw...@odin.mdacc.tmc.edu at work
Disclaimer: Yeah, like I speak for MD Anderson.
Quote: "Boingie"^4 Y,W & D
Hrvoje Brozovic
> Well I have 26 years in programming and I can't see why it's nonsense.
You
> obviously never used a Dec Alpha running NT, which essentially emulated
> Win32 and Win16. If .Net is a portable environment, then the same
> considerations will apply.
My ways crossed with Alpha machines in only two occasions.
First was running Netscape Web server when I worked for
company which was first private Web presence provider in
Croatia, and made constantly refreshing still photos,
live audio and live video, three years in a row first time
in Croatia. Second was real big Alpha for it's time
(4Gb RAM in '97) for bank we was taking care of.
So, yes, I admit, I never run Windows on Alpha.
But, anyway, I know enough to see that your example has
nothing to do with this story. WinNT was compiled to
alpha code, not X86, and there was a way to run
X86 windows binaries in clever emulation mode,
who cached native alpha code provided by x86
interpreter. It was pretty like what NET is doing
with IL today.
And, that system (FX or something) was
advertised as a way to run NON NATIVE
apps, so I really don't see your point.
But, all what is proven by this is that it shakes another
"NET is revolution" claim coming from MS.
Only sane way to interpret "NET will be native API"
sentence is that they will bypass Win32 layer, and
go directly to NTxxx functions. This puts NET in a
level with Win32.
Another thing is that they will expand NET so you
don't have to use a single Win32 call in NET app.
So, claim that "NET will be native API"
can be accepted in relaxed way.
But, there was another claim,
"NET will be the OS", and this is pure nonsense.
How the hell will you BOOT that OS?
How will you protect memory pages???
How are you going to manage devices????
They must create hardware IL processor and
expand its instruction set if they intend to do NET OS.
Anything short of that is not real OS as we know it.
But, MS used term OS for various things in the past.
I have nothing against NET, just I can't figure,
Its MS biggest gamble so far, its Delphi friendly,
and in some time frame I will join.
But, as for Delphi future, I am much more
concerned about lack of support for
future REAL PROCESSORS in Delphi.
If I am not able to produce REAL NATIVE
code, I have no other option than to leave Delphi.
But, I estimate that my Delphi x86 code will run
happily for 5 years at least. I have no doubts
that it will run on Longhorn. But, I am really scared
if 64 bit machines become majority.
Dennis Landi
"Hrvoje Brozovic" <a...@c.de> wrote in message
news:3fdac5d3$1...@newsgroups.borland.com...
> Only sane way to interpret "NET will be native API"
> sentence is that they will bypass Win32 layer, and
> go directly to NTxxx functions. This puts NET in a
> level with Win32.
>
> Another thing is that they will expand NET so you
> don't have to use a single Win32 call in NET app.
>
> So, claim that "NET will be native API"
> can be accepted in relaxed way.
>
Yes, I think this is both the claim and the correct interpretation.
> But, there was another claim,
> "NET will be the OS", and this is pure nonsense.
> How the hell will you BOOT that OS?
> How will you protect memory pages???
> How are you going to manage devices????
>
Right, I don't think the claim is the .NET is the OS...
> They must create hardware IL processor and
> expand its instruction set if they intend to do NET OS.
> Anything short of that is not real OS as we know it.
> But, MS used term OS for various things in the past.
>
> I have nothing against NET, just I can't figure,
> Its MS biggest gamble so far, its Delphi friendly,
> and in some time frame I will join.
>
> But, as for Delphi future, I am much more
> concerned about lack of support for
> future REAL PROCESSORS in Delphi.
>
> If I am not able to produce REAL NATIVE
> code, I have no other option than to leave Delphi.
>
I sure your concerns. I voiced the need for native Delphi-64 bit loudy here
to no avail...
> But, I estimate that my Delphi x86 code will run
> happily for 5 years at least. I have no doubts
> that it will run on Longhorn. But, I am really scared
> if 64 bit machines become majority.
>
As far as I am concerned by the time LongHorn gets here it will be 64-bit...
But as many will point out .NET and D.NET is already 64-bit compliant....
Frankly, I am coming around to the idea of Delphi for .NET on 64-bit. If
MONO can succeed then we even get 64-bit access to other platforms as
well...
-d
Oliver Townshend
> advertised as a way to run NON NATIVE
> apps, so I really don't see your point.
Just to show it was theoretically possible to emulate at different levels.
And I suppose it show that what Native and non-native means is relative.
Don't forget there will be a lot of machines in the future capable of
running .Net if Microsoft has their way, including (already) pocket PCs and
various AMD and Intel 64 bit PCs, for which Win32 will be 'non-native'.
> Only sane way to interpret "NET will be native API"
> sentence is that they will bypass Win32 layer, and
> go directly to NTxxx functions. This puts NET in a
> level with Win32.
Sounds reasonable. Either that or some sort of pseudo-Win32 like the Win16
provided with NT systems.
> Another thing is that they will expand NET so you
> don't have to use a single Win32 call in NET app.
Yep. Don't use many Win16 calls nowadays.
> But, there was another claim,
> "NET will be the OS", and this is pure nonsense.
> How the hell will you BOOT that OS?
> How will you protect memory pages???
> How are you going to manage devices????
With a special bios and kernel written to handle such, written in native
code with .Net hooks?
> They must create hardware IL processor and
> expand its instruction set if they intend to do NET OS.
> Anything short of that is not real OS as we know it.
> But, MS used term OS for various things in the past.
The meaning of OS has always been flexible in my experience. But I can't
see microsoft ever suppling the hardware, just the layers necessary to allow
use to use any sort of chip to run .Net, and eventually make Intel
irrelevant.
> But, I estimate that my Delphi x86 code will run
> happily for 5 years at least. I have no doubts
> that it will run on Longhorn. But, I am really scared
> if 64 bit machines become majority.
Delphi has been flexible enough to be essentially the same design from
Delphi 1 through Delphi 8 encompassing Win16, Win32 and .Net, as well as
(sort of) Linux. I don't think you will have too much to worry about.
Oliver Townshend
Oliver Townshend
believed
> that .net would become "native OS", I was flabbergasted. You need to
> misunderstand about 10 fundamental concepts, not all of which of technical
> nature.
Somehow I think we are arguing about definitions of what exactly native is.
When people first started writing operating systems in C, I imagine you
would have been putting it down as a non-native OS, and an inefficient way
to do things.
> It's like declaring that microcode would be implemented in BASIC.
Thanks for your contribution. It all seems so clear now :)
Oliver
Dennis Landi
degree of confidence that the Win32/64 API will be accessible to native apps
alongside the .NET managed APIs...
"Dennis Landi" <none[at]none.com> wrote in message
news:3fdbcdd3$1...@newsgroups.borland.com...
> "Dennis Landi" <[none][at][none]> wrote in message
> news:uByZ$VEwDH...@TK2MSFTNGP12.phx.gbl...
> > According to this article is appears that .NET will be the native api of
> > LongHorn.
> >
> > http://zdnet.com.com/2100-1107_2-5101117.html
> >
> > Can some knowledgeable person confirm/deny this?
> >
> > I have seen statements on various newsgroups that the Win32/64 API will
> > simply be an emulation on top of the .NET API.
> >
> > True?
> >
> > -d
> >
> >
>
>
> No, Win32/Win64 is not going to be "emulated" on Longhorn.
>
> As usual with Microsoft OS releases, a huge effort will be made to have
> existing Win32 apps run unaltered on Longhorn. Such apps might not take
> advantage of various new features that Longhorn provides, but they should
> work at least as well as they worked on the older OS.
>
> On the other hand, there will be a bunch of new API functionality on
> Longhorn, provided as managed API's. The easiest, most performant, way to
> access that new functionality is going to be by writing your app as a
> managed app. Native apps will still probably be able to call those new
> managed API's, but they might have to write some specific interop code in
> order to do so.
>
> So you'll have choices to make, depending on what you are doing. Writing
a
> brand new app, only for Longhorn? Then the productivity gains of using
> managed code (managed C++, or C#, or possibly another language) are
> hopefully very attractive to you. Updating an existing Windows app, for
> Longhorn? Then you'll have to look at your existing code base, and decide
> whether you want to run the old Windows binary as-is, or recompile the
> binary for Longhorn as native code with specific changes, or perhaps port
> the app to managed C++, or rewrite the app as C# or another language.
>
> --Don
>
> --
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
>
>
>
>
>
Dennis Landi
William Meyer
> Somehow I think we are arguing about definitions of what exactly
> native is. When people first started writing operating systems in C,
> I imagine you would have been putting it down as a non-native OS, and
> an inefficient way to do things.
People did <g>.
> > It's like declaring that microcode would be implemented in BASIC.
>
> Thanks for your contribution. It all seems so clear now :)
LOL!
--
Bill
--------
"You can't keep on doing things the old way and still get the benefits
of the new way." -- Thomas Sowell
Eric Grange
> When I click this link I see a table of contents with no comment on
> your assertion one way or the other.
Upgrate to Internet Explorer 6. No problem viewing it here.
Eric
Craig Stuntz [TeamB]
> Upgrate to Internet Explorer 6. No problem viewing it here.
I have IE 6. See Dennis's comment.
I will make an assertion. Black = white. Here's a URL to back it up:
-Craig
--
Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH
Delphi/InterBase Weblog : http://delphi.weblogs.com
IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt
your DBs! Open Edition users, get 6.0.1.6 from http://mers.com