[Mono-winforms-list] Windows Forms.

Tyler tyler.wilson@acm.org
Tue, 28 Jan 2003 07:16:14 -0800

I tend to be on Gregs 'side' on this one. I would rather see a 'clean' 
WinForms implementation that is as thin and functional as 

I think much of the issue has to do with how Microsoft presents 
.NET the existing Windows programmers, and how those 
developers will then use it. Just perusing the .NET docs, they do 
not make the cross-platform ability of .NET a very big highlight 
item. They do highlight the cross-language ability and the 
migration of knowledge and code that already exists.

>From the developers point of view, I see the Win32-.NET migration 
similar to the DOS-Windows and then Win16-Win32 migration. 
They make it as painless for the developer to move to the next step 
as possible, while keeping them on the MS path. Which is why 
DirectX and Win32s were created. .NET is the same thing. If they 
did not allow programmers to call directly into a WndProc it might 
result in better, cleaner cross-platform code.

But that is not in MSs best interest. Most Win32 programmers are 
accustomed to subclassing, superclassing, etc. to get much of 
their work done. And to recreate this completely in WinForms on 
.NET would either add quite a bit to the size of WinForms, or 'limit' 
the programming to not changing the look of all controls in their 
application or somesuch because they stuck to just the basic 
cross-platform stuff (AWT?).

As for mono, I think it is extremely important to get a WinForm 
implementation in there as soon as possible in whatever way is 
most expedient. After that a lighter-weight non-wine version can be 
done. 'Lazy' apps that need the WndProc hooks can use the Wine 
version. 'Clean' apps can use the simpler cleaner faster(?) 
Qt/GTK+ mono.

My 2 cents,
Tyler Wilson

From: "Greg Brown" <gbrown@molecular.com>
Date: Tue, 28 Jan 2003 09:52:56 -0500

>> What's the point of .NET on Linux if it won't run .NET apps?  
>> Surely 100% is the goal - if Mono can't take advantage of all 
>> the programs that are being or will be written for .NET, why 
>> would anyone install Mono?  There'll always be faster native 
>> code compilers, better windowing toolkits for specific tasks, 
>> better languages for specific domains, and so on.  I thought 
>> Mono was there to bring about a common platform 
>> of the OS and programming language.
>I guess we have different goals for Mono, and specifically 
WinForms on
>Mono. I envision Mono/WinForms as the successor to Java on 
the desktop.
>Like Java, .NET has the potential to become a vehicle for 
>cross-platform applications. Unlike Java, Microsoft is not going to 
>everything it can to prevent it from succeeding.
>In Java, while it is possible to write code that makes calls to 
>APIs, it is generally not necessary, and is often discouraged. The 
>was designed to minimize or eliminate the need to do so for all 
but the
>most performance-intensive tasks. The .NET framework is 
>designed, which leads me to believe that the development 
>would also be similar. Basing the fundamental design of 
Mono/WinForms on
>the need to support a particular platform-specific API (e.g. COM) 
>like it will just enable and encourage bad programming practice.
>Mono-winforms-list maillist  -