[Mono-devel-list] DotGNU competition??

Dennis Hayes denisraytek at yahoo.com
Wed Aug 27 02:07:52 EDT 2003


Another issue is that most SWF controls expose WinProc.
100% managed code can access and override WinProc.
 
I have access to Infragistics source code at work, I should look and see what they do that might be an issue. (of course that is a lot of code to look through).
 
Another issue is that many .NET programs must make calls to windows for other functions. For example, at work most of my programs interface with instruments over a serial port. Wine should allow me to do that.
 
We have a GTK# branch of SWF on Mono, it is motly dead, but every now and then someone checks in some code.
A number of people have posted a desire to do a coco port of SWF for mac, but no one has ever checked in code.
 
The main branch of SWF is Wine.
At this point, most of the people writing SFW code are writting it for Wine.
Personaly, I think it is the right choice.
Also we are pertty far down that path, it would take a strong argumnet to change at this point.
 
You are free to continue the Mono SWF GTK# line of code, or open another line based on something else.
 
Thanks for you comments.
Dennis
 


"Thong (Tum) Nguyen" <tum at veridicus.com> wrote:

It’s worth nothing there are many .NET controls are written in 100% managed code.  I’m pretty sure the major toolkits (Infragistics, Syncfusion, etc) are 100% managed.

 

People using P/Invoke have already given up their “cross platform” compatibility and those applications will become 100% managed over time.  Catering for them isn’t (IMO) important when you consider the “ugliness” of having to integrate with wine.

 

But of course that’s just my opinion.

^Tum


-----Original Message-----
From: mono-devel-list-admin at lists.ximian.com [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Neil Cawse
Sent: Wednesday, 27 August 2003 3:10 p.m.
To: Miguel de Icaza
Cc: mono-devel-list at lists.ximian.com
Subject: RE: [Mono-devel-list] DotGNU competition??

 

>It wont ever be a complete Windows.Forms implementation, as most
>Windows.Forms applications today PInvoke into Win32 to use special
>functionality (most third party controls have to talk to Win32,
>due to limited functionality being exposed by System.Drawing and
>System.Windows.Forms).


I'm not really competent to judge the licensing issues but having written quite a number of c# apps using vs.net, custom controls and now the pnetlib win32 implementation of system.drawing and a number of the key controls - I strongly believe that not basing our implementation on windows messages will *not* hinder broad compatibility, nor completeness.


 


Many of the commercial 3rd party controls currently do make heavy use of the win32 api for a number of reasons. 


However its is rare that end user applications use or need to use interop. As you know on ms runtime you cannot even run an application that does interop from an untrusted location - and this is bound to be tightened even more.



 


Another point worth mentioning is that Avalon (MS next generation UI coming in Longhorn) and its managed interfaces will be integrated as System.Windows.Forms in 1.2 of the Framework. This will be not be compatible with windows messages and applications and controls that use the win32 api for this will not work. Those that stick to using System.Drawing and System.Windows.Forms will.


 


To reiterate, I dont represent any of the opinions of the dotGNU guys.


 


Neil





---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.298 / Virus Database: 161 - Release Date: 13/11/2001



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.298 / Virus Database: 161 - Release Date: 13/11/2001



---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20030826/20e142ea/attachment.html 


More information about the Mono-devel-list mailing list