Re: Delphi refocussing on .Net - good or bad?

Ian,

You cannot talk about such a
big company as if it were a single entity - unless it was a
schizophrenic one ;-)

of course not. matter of fact, you cannot really talk about Microsoft as it it were a single *company*, imho. it's like it's own little ecosystem of companies, which at times even compete or have no clue what their siblings are up to.

fwiw, i'm not saying that's necessarily a bad (or even avoidable) thing.

While I was surprised at the Longhorn Reboot, and how badly MS had
managed the project (and the expectations surrounding the project), I
was not surprised at all to find that Win32-on-.Net was never delivered.

let's say i was surprised/disappointed by how little of it was delivered. did i expect a "fully managed" Longhorn? of course not. that would have been silly, such a major change does not come easily or quickly, nor does it come in a single step. and as i said, i believe it's still *coming*, just at a much slower rate than initially promised/planned/hoped for.

but i had expected more. for example i had (at some stage) expected WPF to be more fully integrated as "the new UI layer", not the lame "addon" it turned out to be. again, this too might change in the future, but it's something that many had (reasonably) expected for Longhorn.

And that's still the case, of course, to a degree - just think the
most obvious one, WPF. Depending on how you want to define "API",
there's certainly other major "features" that are coming out
.NET-only all the time. such as LINQ and WCF, WF (granted not APIs
and you can achieve the same end-goal in managed code, but yet they
stress the remainign focus form Microdoft on making technologies
available in .NET only.

What direction will Office take to use these technologies?

if you look back across these newsgroups, you'll find that i'm one of those people who find it silly to measure Microsoft's commitment to a new platform on their willingness to throw away their probably single largest codebase and rewrite what works fine. that'd be utterly stupid.

so i would not expect Microsoft to "rewrite" office in 100% managed code, and at the same time i would draw absolutely zero relationship between this fact and MS's commitment to .NET as the "future" for development on the Microsoft platform.

That just for the record.

Having said that, there are numerous ways to leverage .NET to develop new features for a product without abandoning your existing code base in Win32.

I hate to mention it (no, who am i kidding, i don't ;), but we at RemObjects sell a product for Delphi developers called Hydra that allows people to do just that -tae their existing, mature Delpgi/Win32 code base and extend their application with new code writtin in .NET, be it WinForms or WPF, or be it non-vidual "algorithm" code that runs behind the scene.

Many of our customers do this, and Microsoft can (and does) do the same thing, by writing modules in .NET and integrating them with their existing Office (and other) unmanaged code applications. Although Microsoft probably won't be using Hydra.

You can read more on my (our, RO's) philosophy on this at http://www.remobjects.com?hy09.

I think that there will certainly be major developments from the .Net
platform: just look at LINQ (I know that you have). I think the
GC-environment provides a good building block for language developers
like yourself to build all sorts of goodies on top of. That's why I
would like to see a high-performance, high ease=of-use interop
solution, to get the best out of both native and .Net - without needing
C++.

Oh, yeah. i'd love a C++/CLI like version of the Oxygene language, that combines managed and unmanaged code, the way it's possible in C++. That'd be absolutely amazing. howeever, i'm afraid it's currently outside of the scope of what we have resources for. currently ;).

--
marc hoffman

RemObjects Software
The Infrastructure Company
http://www.remobjects.com
.

Relevant Pages

  • Re: MVP Award...
    ... But outside of Microsoft toolset, there is no clone VB, and standard C++ would be dominate. ... Now, in my client/server market where we offer a multi-language client SDK, VB/VB.NET and WCBASIC clearly are the #1 language used for client/server development by APPLICATION developers. ... As these vendors "evolve" their platform, making it more complex, etc, I don't see this massive movement to it and many stick to the last stable/older version. ...
    (microsoft.public.vc.mfc)
  • Re: Comparison about Win32 / DotNet / CSharp on Delphi, and a wish ...
    ... Microsoft has no problem with alternative ... And thats what they are doing right now with their .Net and Win32 support. ... According to their roadmap another platform will be Win64 native.. ... Application server enabling technology for developers ...
    (borland.public.delphi.non-technical)
  • Re: why Microsoft Developers not like others developers (Java Dev, Linux Dev, etc)?
    ... developers' 'linux developers',... ... Very few developers are fixed to a specific platform, ... With that out of the way, I don't think it is fair to say that Microsoft ...
    (microsoft.public.dotnet.languages.vc)
  • Re: What this mean for Borland?
    ... But actions speak more then words, and Microsoft has, imho, a strong history of showing that developers are important to them (even beyond Ballmer doing the ... That's not because Microsoft are nice guys, or more trustworthy as far was large corporations go; it's because Microsoft sees developers as the foundation of their success and as the partners that make their core business (the platform) thrive, - by making Windows a lively platform with an endless variety of available applications. ... In contrast, Borland apparently sees developers as pesky customers who are getting in the way of they shareholder value ...
    (borland.public.delphi.non-technical)
  • Re: Support for optional parameters
    ... programming language, but THE central programming language of the .Net ... Office being THE cash cow at Microsoft, well, forgive me for restraining my ... The success of the VSTO initiative and the success of Office are two ... >> sure it comes in handy for a few developers out there from time to time. ...
    (microsoft.public.dotnet.framework)