[Mono-winforms-list] Windows Forms.

Reggie Burnett rykr@bellsouth.net
Mon, 27 Jan 2003 22:59:36 -0600

While I agree that the purity of a non-WineLib implementation is nice =
and a completely platform independent windowing toolkit would be very =
sweet, the fact is that most of the .Net apps will be written on Windows =
using the MS .NET SDK.  Certainly Mono is being written not only to help =
develop apps on other platforms but to make these other platforms more =
viable destinations as more and more apps become .Net apps.  This would =
not be the case if a new, incompatible Windowing toolkit were used for =
Mono's SWF.  Certainly the new toolkit could be used by the Windows =
crowd, but what are the chances...

To realize one of the dreams of Mono (running SWF apps on Linux and =
others), WineLib may be the only viable choice.


> -----Original Message-----
> From: mono-winforms-list-admin@lists.ximian.com [mailto:mono-winforms-
> list-admin@lists.ximian.com] On Behalf Of Joshua Perry
> Sent: Monday, January 27, 2003 9:37 PM
> To: mono-winforms-list@ximian.com
> Subject: RE: [Mono-winforms-list] Windows Forms.
> Of course you can't blame Microsoft for making heavy use of windows in
> their classes.  Looking at it from a different perspective, I suppose =
> we are looking for is a way for SWF apps to work seamlessly on X =
> any changes.  For this I agree that Wine would be a great solution for =
> problem.  However, I just do not want it to become the rule, I believe =
> would much better for everyone involved if future applications, and =
> that are easily ported, were written in a truly cross-platform =
> library.
> I suppose it all boils down to where you want the platform dependence =
> be.  It can be at the same level as the SWF library, where you have to
> worry about the correct DLL being in the GAC.  Or it can be at the =
> of the toolkit(GTK, QT, etc), where you have to worry about making =
> GTK or what have you and its dependencies are installed.
> Perhaps we just need to dive in and make a cross-platform windowing
> toolkit in pure .NET, or perhaps not...
> 	-----Original Message-----
> 	From: Dennis Hayes [mailto:DENNISH@Raytek.com]
> 	Sent: Mon 1/27/2003 7:09 PM
> 	To: mono-winforms-list@ximian.com
> 	Cc:
> 	Subject: RE: [Mono-winforms-list] Windows Forms.
> 	We could get some implmentation of SWF using GTK, but I think the
> effort
> 	should go instead to fixing WINE. It looks like it is not that
> difficult. If
> 	we post this list of what needs to be implmented to the WINELIB
> list, they
> 	might even do it for us. the WINE people have indicated that  fixing
> 	to be pthreads compatable would be too much work. If they knew
> exactly what
> 	needed to be fixed for Mono, they might be more willing to do it.
> 	All classes in SWF that display a control have WinProc as one of
> their
> 	functions.
> 	Any soultion that that does not use WINE will need to either match
> the
> 	events from windows, or replace WinProc with something else to
> create and
> 	process the messages. The people working on WINE point out that in
> many
> 	cases the order the messages are sent in are importiant, and that
> getting
> 	the message order right was often more difficult than implmenting
> the
> 	message. Readng on list how messages can be different depending on
> wheater
> 	the control is on a form or in a container (yes I know a form is a
> 	container, but...).
> 	Here is the list of what needs to be implmented in WINE (actualy
> moved from
> 	pthreads to WINE)
> 	this is copied from an email from Migule. note that some of these
> are
> 	duplicated.
> 	Dennis
> 	   This is what is missing.  Notice that I removed the -lpthread
> from
> 	the build, this will get you the routines missing (sem_destroy,
> 	sem_wait, sem_post)
> 	mono$ cc -shared -Wl,-Bsymbolic -D_REENTRANT -DWINELIB -o
> monostub.exe.so
> 	monostub.exe.spec.o monostub.o monostub.exe.dbg.o -
> I/usr/local/include
> 	-L/usr/lib /mono/lib/libmono.a  -lgc -lwine -lntdll.dll `pkg-config
> --libs
> 	glib-2.0` `pkg-config --libs gmodule-2.0` -lm
> 	/mono/lib/libmono.a(threads.lo): In function
> 	`ves_icall_System_Threading_Thread_Abort':
> 	/cvs/mono/mono/metadata/threads.c:1155: undefined reference to
> 	`pthread_kill'
> 	/mono/lib/libmono.a(timed-thread.lo): In function
> 	`_wapi_timed_thread_create':
> 	/cvs/mono/mono/io-layer/timed-thread.c:114: undefined reference to
> 	`sem_init'
> 	/mono/lib/libmono.a(timed-thread.lo): In function
> 	`_wapi_timed_thread_attach':
> 	/cvs/mono/mono/io-layer/timed-thread.c:144: undefined reference to
> 	`sem_init'
> 	/mono/lib/libmono.a(timed-thread.lo): In function
> 	`_wapi_timed_thread_destroy':
> 	/cvs/mono/mono/io-layer/timed-thread.c:198: undefined reference to
> 	`sem_destroy'
> 	/mono/lib/libmono.a(timed-thread.lo): In function
> 	`_wapi_timed_thread_suspend':
> 	/cvs/mono/mono/io-layer/timed-thread.c:231: undefined reference to
> 	`sem_wait'
> 	/mono/lib/libmono.a(timed-thread.lo): In function
> 	`_wapi_timed_thread_resume':
> 	/cvs/mono/mono/io-layer/timed-thread.c:236: undefined reference to
> 	`sem_post'
> 	>Joshua Perry [Jperry@1800contacts.com] wrote:
> 	>It seems to me that our problem is not implementing
> System.Windows.Forms.
> 	> Our problem is rooted > in the fact that Microsoft has defined a
> library
> 	> that is not able to be platform independent,
> 	> thats just for things like the WndProc problem.
> 	I can't blame Micorsoft for writing classes that make hevy use of
> windows.
> 	I Assume this is one reason they did not include SWF in the ECMA
> standards.
> 	Dennis
> 	-----Original Message-----
> 	From: Miguel de Icaza [mailto:miguel@ximian.com]
> 	Sent: Sunday, January 26, 2003 11:16 AM
> 	To: mono-winforms-list@ximian.com
> 	Subject: [Mono-winforms-list] Windows Forms.
> 	Hey guys,
> 	    So we have a problem with Windows.Forms right now.  To
> test/develop
> 	on Linux we need to get Wine to include support for a few semaphore
> 	calls.
> 	    As said before, Winforms implemented with Wine is required to
> have
> 	full support for Wndprocs and P/Invokes, and is the right way of
> doing
> 	things.
> 	    The other option that we have scratched is to build
> Windows.Forms
> 	using a native toolkit, because we would not be able to achieve 100%
> 	compatibility.
> 	    Idea: it would be useful to have a Windows.Forms implementation
> that
> 	used Gtk# at least to port existing Open Source Winforms code that
> we
> 	could tweak or ifdef chunks of code.
> 	    Opinions?
> 	Miguel
> 	_______________________________________________
> 	Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
> 	http://lists.ximian.com/mailman/listinfo/mono-winforms-list
> 	_______________________________________________
> 	Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
> 	http://lists.ximian.com/mailman/listinfo/mono-winforms-list
> 2 )=DF=A2+-+-2 )=DF=A2+-+-=18=DC=A2hm+-=18 oj)fj=7F b=CB=9D? ) +-