Re: Thinking Clearly

Dan Barclay wrote:
"Andre Kaufmann" <andre.kaufmann_remove_@xxxxxxxxxxx> wrote in message
>[...]
a) WPF (aka Avalon) is a .NET layer only. If VCL will support WPF
>[...]

.Net layer only, without going to the OS unmanaged code? I admit I haven't followed that but when I get time it'll be interesting to see. Getting to the iron, bypassing OS drivers, is usually dangerous.

Not quite bypassing OS. Sorry for being not precise enough.
Surely the new Windows Presentation Framework, the 3D GUI, has also a native layer and doesn't bypass OS drivers. The native layer for WPF is DirectX. But large parts of the WPF framework are managed code. Would be just the same situation for GDI, if Win32 GDI would be in managed code. You want to draw a box, button etc. then you would have to call into the hypothetical managed GDI or do it natively by your own.

So any native application targeting WPF would either have to call into managed code or would have to re-implement the whole WPF framework in native code.

b) There is plenty of .NET code in the framework, which doesn't
sit directly on Win32.

.Net is an application running on the OS, so far as I understand.

Yes and no. ;-) . IIRC .NET runtime is not running permanently, but the ..NET runtime, which provides memory, does garbage collection etc. is loaded and shared with every .NET application.
And yes it's running on the OS as every Win32 application ;-)

It gets its memory by asking the OS for memory, in interacts with the hardware by asking the OS for things and moves on from there. Or did I miss something?

It's just the same as in native applications. So far you didn't miss something. ;-). IIRC VB has been for a long time compiled to byte code, which has been interpreted by a runtime. Just another execution layer and somewhat comparable to .NET, except that .NET compiles on the fly to native code and doesn't interpret it over and over again.

There are (at least one) native compilers, which compile a managed applications and the used parts of the framework, to native code. So that you can ship and run them without having the .NET framework installed. Haven't tried it, but IMHO these application will be rather larger.

You are even able to precompile a .NET application, so that there isn't that much difference to a native one anymore (despite needing a large framework ;-) )


[...]
IMHO it will be quite unlikely (though technically not impossible I suppose) to see an unmanaged OS functionality on top of a managed OS. Remember, even a managed OS has unmanaged code to do the managing <vbg>. From a practical standpoint I don't expect to see this for a long time. But, I was wrong before (I thought the number of VB users would matter to MS<g>).

Well, there is a pure managed research OS called Singularity. It doesn't work like any other traditional OS. Perhaps it's the future of Windows, perhaps not - I don't know. We'll see. Anyways IMHO it must emulate Win32 and be able to run native applications to be successful. If it will ever ship.

This wasn't the first time. They changed a fundamental data type with
[...]
They need to be *very* careful about that. They already have different string types so they should be able to manage a Unicode change without breaking code, particularly binary data code. You can quote me: "A new type of data requires a new data type!" You can start the chant anytime<g>.

For 64 bit applications it's IMHO a valid decision to change the framework. Since you cannot use 32 bit components, they all must have to be recompiled. And you don't need a binary compatibility anymore. Source code compatibility will be sufficient.
For 32 bit applications, changing code parts of the VCL would break many existing 32 bit VCL components.

Dan


.

Relevant Pages

  • Re: VCL.Net a hack?
    ... VCL for .NET is a full framework for creating applications ... VCL.NET uses Win32 functions and messages internally. ... code than, say, applications), but that doesn't make it a hack. ...
    (borland.public.delphi.non-technical)
  • Re: Competition is not ALWAYS good
    ... you see web framework as a must-use product. ... their applications in bare PHP -- and be quite successful with this. ... SB> is a religion then yes I am religious. ... so for people who actually want application up and running portability has ...
    (comp.lang.lisp)
  • Re: VB6Twilighted --
    ... > interface for lynix, mac, alpha, windows, and what-ever platforms. ... We call this compiled class library the REALbasic Framework, ... compiles to x86 and PowerPC machine code, not p-code, and does not make use ... it is to de-compile .NET bytecode, exposing the source code. ...
    (microsoft.public.vb.general.discussion)
  • Re: .Net Framework 2.0
    ... We just found in our same legacy application (because focus is currently on ... When the Framework went from 1.0 to 1.1 in this ... and implement wrappers for our .Net components that create custom App ... have the problem that when our applications run under 3rd party vendor host ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Article: - David Intersimone on DevCo, the viability of Delphi, and Turbo Ruby
    ... Inventing NET/CLR allows MS to have total control over the execution environment. ... C++ had to be badly mangled to get it to work with the .NET framework so I really don't think this was a valid objective. ... Look at how much of the GUI magic in Vista is now tied into .NET so you can't do it with older Win32 apps. ... ..NET has no real advantage over Win32 and has many disadvantages such as speed, performance and the fact it only runs in full form on Windows, compared to Java everywhere. ...
    (borland.public.delphi.non-technical)