Is .NET to replace Win32?

[Phill]

I'm still new to .NET and come from a win32 background.

I'm happy w/ what I see in .NET although it is a little slower than
I'd like. It also has a nice oo design and C# is a wonderful language
to write in.

But is this designed to be like a newer/better MFC that will always
rest on top of win32 or something like it? Or will .NET take over as
THE WAY to write Windows software?

Thanks.

[Joep]

On top of something, definitely until ... (but that takes time)
The way? That's up to you.

[Nicholas Paldino [.NET/C# MVP]]

Phill,

Right now, it generally rests on top of Win32 for some of it's
functionality (for example, the classes in the System.Windows.Forms
namespace). However, Avalon will change that. The codebase for Avalon is
managed code (as is Indigo and WinFx), and there will be no unmanaged code
interface. If unmanaged code wants to connect to these things, then it will
have to get an unmanaged code wrapper for the managed code.

This doesn't mean that advancements in the Win32 platform won't take
place. Take for example the fact that NTFS is going to be come
transactional. There is a Win32 entry point for beginning/ending the
transaction, and will probably have a managed entry point as well.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Phill" <wa********@yahoo.com> wrote in message
news:ac*************************@posting.google.co m...

I'm still new to .NET and come from a win32 background.

I'm happy w/ what I see in .NET although it is a little slower than
I'd like. It also has a nice oo design and C# is a wonderful language
to write in.

But is this designed to be like a newer/better MFC that will always
rest on top of win32 or something like it? Or will .NET take over as
THE WAY to write Windows software?

Thanks.

[Willy Denoyette [MVP]]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:OQ**************@TK2MSFTNGP11.phx.gbl...

Phill,

Right now, it generally rests on top of Win32 for some of it's
functionality (for example, the classes in the System.Windows.Forms
namespace). However, Avalon will change that. The codebase for Avalon is
managed code (as is Indigo and WinFx), and there will be no unmanaged code
interface. If unmanaged code wants to connect to these things, then it
will have to get an unmanaged code wrapper for the managed code.

Nicholas,

Not sure where you get this from? Indigo relies on COM interop for
bootstrapping, and through COM interop it enables unmanaged code to be
exposed as WS-x services and by the same way services can be consumed from
unmanaged code. Indigo also relies on Win32 for it's OS services and needs
unmanaged components as hosting services (http.sys or asp.net).

Willy.

[John Bailo]

Phill wrote:

I'm still new to .NET and come from a win32 background.

I'm happy w/ what I see in .NET although it is a little slower than
I'd like. It also has a nice oo design and C# is a wonderful language
to write in.

But is this designed to be like a newer/better MFC that will always
rest on top of win32 or something like it? Or will .NET take over as
THE WAY to write Windows software?
Take over.

All of the new so-called 'operating system' features that microsoft has
proposed so far in Longhorn, should simply be .NET implementations.

As far as win32 -- absolutely -- win32 type operations should be completely
wrapped in the .NET object layers.

Thanks.

--
http://antimeme.texeme.com

[Joep]

Just thinking, first an IL processor in hardware, probably microcode
initially like in the 'old' days (mainframe is still here), then what? The
important new thing being things becoming available for the masses in a nice
format. Any thought anyone?

[Nicholas Paldino [.NET/C# MVP]]

Willy,

I'm not saying that the implementations are devoid of unmanaged code
(you are right, there is a good amount of unmanaged code on the Indigo
side), but rather, the interfaces are going to be through managed code, as
well as the majority of the implementation.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:e9**************@TK2MSFTNGP12.phx.gbl...

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:OQ**************@TK2MSFTNGP11.phx.gbl...

Phill,

Right now, it generally rests on top of Win32 for some of it's
functionality (for example, the classes in the System.Windows.Forms
namespace). However, Avalon will change that. The codebase for Avalon
is managed code (as is Indigo and WinFx), and there will be no unmanaged
code interface. If unmanaged code wants to connect to these things, then
it will have to get an unmanaged code wrapper for the managed code.

Nicholas,

Not sure where you get this from? Indigo relies on COM interop for
bootstrapping, and through COM interop it enables unmanaged code to be
exposed as WS-x services and by the same way services can be consumed from
unmanaged code. Indigo also relies on Win32 for it's OS services and needs
unmanaged components as hosting services (http.sys or asp.net).

Willy.

[Bonj]

If you wanted to eliminate Win32 completely you'd probably have to have a
processor that can understand MSIL. I don't know whether there currently are
any or plans to make them, but I did hear a rumour that MS were planning to
liase with chip manufacturers in something called 'palladium' whereby the
chip itself would ensure that only trusted / licensed code could run. How
far they'll get with it and whether it'll be successful I don't know, it
really depends on how consciencious they are about encouraging amateur
developers to get their work out to people - it could be said (or hoped)
that they see this as commercially important aswell as morally. However I
can't see anything wrong with chips that can understand MSIL that anybody
can write code for, if it would be technically viable at the low level.

"Phill" <wa********@yahoo.com> wrote in message
news:ac*************************@posting.google.co m...

I'm still new to .NET and come from a win32 background.

I'm happy w/ what I see in .NET although it is a little slower than
I'd like. It also has a nice oo design and C# is a wonderful language
to write in.

But is this designed to be like a newer/better MFC that will always
rest on top of win32 or something like it? Or will .NET take over as
THE WAY to write Windows software?

Thanks.

[Willy Denoyette [MVP]]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:Om**************@TK2MSFTNGP10.phx.gbl...

Willy,

I'm not saying that the implementations are devoid of unmanaged code
(you are right, there is a good amount of unmanaged code on the Indigo
side), but rather, the interfaces are going to be through managed code, as
well as the majority of the implementation.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

Nicholas ,
Your reply:
/
The codebase for Avalon is managed code (as is Indigo and WinFx), and there
will be no unmanaged code
interface. If unmanaged code wants to connect to these things, then it will
have to get an unmanaged code wrapper for the managed code.
/
My point is that Indigo will also provide interfaces for unmanaged service
consumers and providers, so that they can "seamlessly" integrate within the
service oriented architecture.
Indigo wouldn't be accepted if they would exclude or make it hard to
interface with unmanaged code, you don't think everyone is switching to
managed code do you? ;-) .

Willy.

[William Stacey [MVP]]

Win32 (or Win64) will always be between the metal and managed code (unless
they get those special cpus other poster talked about.) Winfx will try to
wrap most/all apis in managed code and create new apis in managed code when
reasonable to do so.

--
William Stacey, MVP

"Phill" <wa********@yahoo.com> wrote in message
news:ac*************************@posting.google.co m...

I'm still new to .NET and come from a win32 background.

I'm happy w/ what I see in .NET although it is a little slower than
I'd like. It also has a nice oo design and C# is a wonderful language
to write in.

But is this designed to be like a newer/better MFC that will always
rest on top of win32 or something like it? Or will .NET take over as
THE WAY to write Windows software?

Thanks.

[Joep]

Chips that are loaded with micro code have existed for over 30 years now.
Given micro code X the chip behaves like processor X, given micro code Y it
behaves like processor Y. Micro code can be hard or soft.

Desktop processors have micro code burned into them. On top of that we have
the bios in ROM. Sofar the hard part. What's loaded into RAM is the soft
part.

Given the increase in capacity I see the layers descend into the processor
step by step. Not a problem, it just takes time.

[Gareth Rowlands]

"Joep" <St***@DeStoep.nl> wrote in message
news:41***********************@news.xs4all.nl...
....

Given the increase in capacity I see the layers descend into the processor
step by step. Not a problem, it just takes time.

Processors that have IL as their native instruction set aren't gonna happen.
Processors are all about executing instructions as fast as possible, which
means keeping them simple. Compiler technology takes care of briding the
gap. There is no trend of processors working up the layers - if there was
then processors that run JVM or LISP would be common by now.
--Gareth

[Joep]

It's not all about imagination, have a look at the good old IBM mainframe
and its IPL and think about emulation. Moore's law has not yet come to an
end, mechanic memory clocks at 23,5 Mhz in test which is a little bit faster
than what we have commercially available today with magnetic disks (look for
Mohanty/Boston if you would like to know more about it), can you imagine?
What about graphics cards? They have been absorbing what used to be done in
software, right? So there is a trend of moving what was done in software
down to the hardware level. The debate between RISC and CISC has not yet
come to an end. What about a compiler that programs a PLA? I see no
technical reason that would prevent this - it is technically possible today,
only commercial reasons migth interfere.

Let's see what the future brings in this field, ok?

[Joep]

Micro-code is not the same as IL by the way, just in case.

[Phill]

I understand that something like WIN32/WIN64 must exist. I wasn't very
clear. What I meant was, is .NET programming going to replace Win32
programming as the dominant or preferred way to write Windows
Programs. And will Win32 programming go away?

[No One]

Technically, Win32 was replaced by MFC as the way to make Windows
programmes, but too many Win32 programmers complained and MFC was dumbed
down. Personally, I have written programmes by all three methods and I
much prefer .Net, albeit that VS.Net is a highly dumbed down tool and
needs vast improvement.

Phill wrote:

I understand that something like WIN32/WIN64 must exist. I wasn't very
clear. What I meant was, is .NET programming going to replace Win32
programming as the dominant or preferred way to write Windows
Programs. And will Win32 programming go away?

[Anders Borum]

> Technically, Win32 was replaced by MFC as the way to make Windows

programmes, but too many Win32 programmers complained and MFC was dumbed
down. Personally, I have written programmes by all three methods and I
much prefer .Net, albeit that VS.Net is a highly dumbed down tool and
needs vast improvement.

I'm sure Microsoft are continously working on VS .NET. Personally I haven't
used the new whidbey release yet, but my impression is that it's a "vast
improvement" compared to the current 2003 version (according to feedback
from our developers).

--
venlig hilsen / with regards
anders borum
--