Board index » cppbuilder » Re: If MS Doesn't Break Win32 API support why migrate to DOT NET?

Re: If MS Doesn't Break Win32 API support why migrate to DOT NET?


2003-11-14 07:39:57 AM
cppbuilder1
"Dave Jewell" < XXXX@XXXXX.COM >wrote:
Quote
Yeah, that would be the same reliable source who told us that W95 would be
all-new, fully 32-bit code, right?
Never heard that, myself. W95 was always going to be a hotchpotch.
What _was_ incorrect was that it was going to be the last.
Alan Bellingham
--
Team Thai Kingdom
<url:www.borland.com/newsgroups/>Borland newsgroup descriptions
<url:www.borland.com/newsgroups/netiquette.html>netiquette
 
 

Re:Re: If MS Doesn't Break Win32 API support why migrate to DOT NET?

That's the whole point. If MS are re-writing LongHorn in .NET then the OS is
the same whether it is 32bit/64 bit/128 bit. It's just the compiler that's
different.
It will make supporting windows on new platforms/processors easier and
because most of the code is managed it *should* reduce the buffer overflows
etc that give them such a bad security record.
But that's just what the reputable person was told (but it makes sense to
me).
Rgds Pete
"Randall Parker" < XXXX@XXXXX.COM >wrote in
message news:3fb3cde1$ XXXX@XXXXX.COM ...
Quote
Pete,

It takes a long time to stabilize new code. Think about how big WinXP's
code base is. It would be madness to rewrite the whole thing.

MS has been preparing for 64 bit migration for a long time and will have
64 bit support out before LongHorn, right? So they will have to bring
out some sort of Win64 API that includes lots of equivalents for Win32
API calls that are not .NET calls. Once they have all that Win64 code
stabilized why replace it with .NET code?

Pete Fraser wrote:

>I've heard from a reliable source that LongHorn code will be 85% .NET
and
>the other 15% is drivers at a lower level. There is thus NO Win32 in the
>main OS. Win32 support therefore *must* be on top of .NET and thus
slower -
>but more secure. This is why LongHorn is taking so long to come through.
>HTH Pete
>

 

Re:Re: If MS Doesn't Break Win32 API support why migrate to DOT NET?

"Pete Fraser" wrote:
Quote
That's the whole point. If MS are re-writing LongHorn in .NET then the OS
is
the same whether it is 32bit/64 bit/128 bit. It's just the compiler that's
different.
I suppose you mean the runtime is different. The compiler just compiles to
bytecode wich is interpreted/jitted by the runtime.
Quote
It will make supporting windows on new platforms/processors easier
The only thing wich has to be ported is the .NET runtime. This can be done
in two ways: .NET is the OS (Longhorn) or it is a layer on a host OS (Mono).
Quote
and
because most of the code is managed it *should* reduce the buffer
overflows
etc that give them such a bad security record.
Every type in .NET is an object. So when .NET states that an integer is 32
bits, it can assure it is 32 bits on every platform. That the runtime for
performance reasons uses a native 64bit 'integer' when available doesn't
matter.
Peter
 

{smallsort}

Re:Re: If MS Doesn't Break Win32 API support why migrate to DOT NET?

"Alan Bellingham" < XXXX@XXXXX.COM >wrote in message
Quote
Never heard that, myself. W95 was always going to be a hotchpotch.
At the time, there was all sorts of flannel from Microsoft about the core
modules being totally 32-bit 'under the hood'.
Quote
What _was_ incorrect was that it was going to be the last.
Yeah, I guess that really *would* have been too much to hope for. ;-)
Dave
 

Re:Re: If MS Doesn't Break Win32 API support why migrate to DOT NET?

"Peter Agricola" < XXXX@XXXXX.COM >wrote in message
Quote

"Pete Fraser" wrote:
>That's the whole point. If MS are re-writing LongHorn in .NET then the
OS
is
>the same whether it is 32bit/64 bit/128 bit. It's just the compiler
that's
>different.

I suppose you mean the runtime is different. The compiler just compiles to
bytecode wich is interpreted/jitted by the runtime.

Yes, I meant the runtime byte code interpreter/compiler.
I think that while .NET must be slower because of the run time
interpretation
the actual idea behind .NET of platform independence is good. It might mean
the MS
can deliver windows on different hardware platforms more easily (as in
Compact framework etc.).
Not that I like the idea of MS dominating more platforms....
Rgds Pete