[Mono-devel-list] How can Mono Existing if WinFX, Avalon, Indigio and Aero comes up with Longhorn and WinXP?
dru at druware.com
Mon Sep 13 11:40:03 EDT 2004
Please, take this flame bait troll elsewhere.
First, this is a discussion of Mono development related issues, and not
a Java advocates list, many if not most of us on this list have Java
experience in addition to Mono/C#.
Second, Sun is in no position to buy Novell right now.
Third, Java is, at this point at as much risk of being orphaned as Mono
is. At least C# is an ECMA standard, and the Mono code is OSS. Java
is neither, and Sun is at as much risk, if not more, since Sun's
revenue is falling off, and the potential for it to return in the short
term isn't very good.
Fourth, Microsoft cannot at this point kill non-managed code, for that
would in fact render your own arguments irrelevant, since that would
also effectively kill all legacy code, including vast quantities of
Microsoft code that corporate enterprise level companies rely on. At
this point, Microsoft hasn't even had to time or inclination to fix
their Application Center software to *PROPERLY* deal with Managed Code.
BizTalk just barely deals with Managed Code, SQL Server as it's
shipping doesn't either. Migrating those tools to Managed Code is a
project that will encompass the next 10 years at Microsoft.
In short, please remove your head from the sand, and think. Microsoft
is advocating .NET and managed code because they have to, but they
aren't going to cut their own throat. Longhorn is not going to ship as
they've described it, and if you had spent as much time in this
industry as many of us, you would remember that this is not the first
time that MS has promised a product (Cairo) that including some amazing
technology ideas (the Object File System, a fully Object Oriented
Workplace Shell, Powerfull Meta-data support, widespread pervasive
Distributed COM) and then castrated the release until it became Windows
NT 4, and then trickled out the innovations in 'Service Packs' and
other cruft, or never finished them, renamed them and foisted the same
bright ideas as revolutionary and new to those gullible enough to buy
into it regarding WinFS (OFS built on Yukon, only hacked together via
FS hooks on top of NTFS instead of being a real new file system with
anything revolutionary). Oh and Avalon, Indigo, and the rest... If
you buy that all new apps will be ported to them in the next 10 years,
you are smoking something.
dru at druware.com - druware software designs
On Sep 13, 2004, at 10:06 AM, falkmilan at yahoo.de wrote:
> Nathan Neitzke wrote:
>> I think you are mistaken. WinFX will NOT run alongside the .NET
>> WinFX will run *within* the .NET framework. It will be a *managed*
>> API that
> I know this and thadt it was sayed.
>> your application can use. It must be understood that whether or not
>> WinFX API makes native calls is *completely* transparent to the WinFX
>> user. They are just calling managed code as far as they are
>> If under mono the WinFX classes are implemented it doesn't matter what
>> operating system/windowing system/os api it calls to get the job done
>> - just
>> that has the same interface as the WinFX API.
> Yeah. you want port the whole closed SourceWinFX API for .NET,ok
> thadt willbe a Fine work!
> Remember WinFX is not alone, it comes with Avalon (GUI-Layer with
> Aero) , Idigio (Networking
> and EnhancedWebservices) and Moand (Commandlineshell and Scripting
> How do you think how long you can rewrite a Mono Version of WinFX and
> its closed
> Source Parts if Microsoft every Month putting new Things on the Market?
> Microsoft is an Giant and not intresting to Support Linux or Novell
> and it is clear thadt
> they want make some nasty Tricks to make it happend.
> No, i think the only Way is to goto Java and write Windows Appz and if
> the Rumors about
> SUN will buy Novell is true, then Mono is gone anyway.
> I dont belive thadt MS would support Linux and Mono, and it is more
> sure you are running
> into Trouble, if the only Thing you are doing is to adopt Windows
> Things to Mono.
> Maybe it is an better Choice, to Make a Own, not Micorosft specially
> targeted VM
> Technologie. All things should be written in Bytecode (or however you
> it called) and only
> the JVM Layer should be native (or based on Devicedriver and/or Kernel
> The Advantage is, you can write Easy an Device Driver thadt Hosts the
> VM and on its
> inside runs the Application untouched - like Java Appz does.
> A Free Java Projekt for Example.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list