[Mono-winforms-list] Windows Forms.

Dennis Hayes DENNISH@Raytek.com
Mon, 27 Jan 2003 18:09:04 -0800

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 WINELIb
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
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

   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
/cvs/mono/mono/metadata/threads.c:1155: undefined reference to
/mono/lib/libmono.a(timed-thread.lo): In function
/cvs/mono/mono/io-layer/timed-thread.c:114: undefined reference to
/mono/lib/libmono.a(timed-thread.lo): In function
/cvs/mono/mono/io-layer/timed-thread.c:144: undefined reference to
/mono/lib/libmono.a(timed-thread.lo): In function
/cvs/mono/mono/io-layer/timed-thread.c:198: undefined reference to
/mono/lib/libmono.a(timed-thread.lo): In function
/cvs/mono/mono/io-layer/timed-thread.c:231: undefined reference to
/mono/lib/libmono.a(timed-thread.lo): In function
/cvs/mono/mono/io-layer/timed-thread.c:236: undefined reference to

>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.

-----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 API

    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

    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%

    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.



Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com