[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.
Reggie
> -----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.
>=20
> 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 =
what
> we are looking for is a way for SWF apps to work seamlessly on X =
without
> any changes. For this I agree that Wine would be a great solution for =
the
> problem. However, I just do not want it to become the rule, I believe =
it
> would much better for everyone involved if future applications, and =
any
> that are easily ported, were written in a truly cross-platform =
windowing
> library.
>=20
> I suppose it all boils down to where you want the platform dependence =
to
> 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 =
level
> of the toolkit(GTK, QT, etc), where you have to worry about making =
sure
> GTK or what have you and its dependencies are installed.
>=20
> Perhaps we just need to dive in and make a cross-platform windowing
> toolkit in pure .NET, or perhaps not...
>=20
> -----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.
>=20
>=20
>=20
>=20
> 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.
>=20
> 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...).
>=20
> 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
>=20
>=20
> 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)
>=20
>=20
> 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'
>=20
> >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.
>=20
> 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.
>=20
> 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.
>=20
>=20
> Hey guys,
>=20
> 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
> calls.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Opinions?
>=20
> Miguel
>=20
>=20
> _______________________________________________
> 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
>=20
>=20
> 2 )=DF=A2+-+-2 )=DF=A2+-+-=18=DC=A2hm+-=18 oj)fj=7F b=CB=9D? ) +-