nanogui: Thread: microwin & client/server

howdy,
do you try twin project: http://www.willows.com
i think the best solution of microwin & client/server
is to make microwin program as  a nano-x client
& probably make those windows api in share library
:)

On Wed May 10, 2000 at 04:25:33PM +0800, ´¿¬L©ú wrote:
> howdy,
> do you try twin project: http://www.willows.com
> i think the best solution of microwin & client/server
> is to make microwin program as  a nano-x client
> & probably make those windows api in share library
> :)

Back when TWIN was first GPLed I spent some time porting it to GNU libc from
libc5.  So I have some experience and familarity with the code.  TWIN is BIG.
It aims to provide cross platform win32 ABI and API support.  It would be a
huge job to take TWIN and make it appropriate for embedded systems because it
is so big.

That said, I suspect that microwindows would benefit greatly if someone were to
take the windows controls from TWIN (i.e. buttons, combo boxes, etc) and make
them use only win32 calls (no TWIN internals) and make them all work with
microwindows.

 -Erik

--
Erik B. Andersen   Web:    http://www.xmission.com/~andersen/ 
                   email:  ####@####.####
--This message was written using 73% post-consumer electrons--

try to connect microwin as nano-x client:
http://members.xoom.com/jauming/mwin2.tar.gz
seem to be able to co-work with other nano-x client
event connect is ok
still need graphic connect..
"server": bin/nano-X
"client": bin/mtest

----- Original Message -----
From: Erik Andersen ####@####.####
To: 曾昭明 ####@####.####
Cc: ####@####.####
Sent: Thursday, May 11, 2000 12:27 PM
Subject: Re: microwin & client/server


> On Wed May 10, 2000 at 04:25:33PM +0800, 曾昭明 wrote:
> > howdy,
> > do you try twin project: http://www.willows.com
> > i think the best solution of microwin & client/server
> > is to make microwin program as  a nano-x client
> > & probably make those windows api in share library
> > :)
>
> Back when TWIN was first GPLed I spent some time porting it to GNU libc
from
> libc5.  So I have some experience and familarity with the code.  TWIN is
BIG.
> It aims to provide cross platform win32 ABI and API support.  It would be
a
> huge job to take TWIN and make it appropriate for embedded systems because
it
> is so big.
>
> That said, I suspect that microwindows would benefit greatly if someone
were to
> take the windows controls from TWIN (i.e. buttons, combo boxes, etc) and
make
> them use only win32 calls (no TWIN internals) and make them all work with
> microwindows.
>
>  -Erik
>
> --
> Erik B. Andersen   Web:    http://www.xmission.com/~andersen/
>                    email:  ####@####.####
> --This message was written using 73% post-consumer electrons--
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

: Back when TWIN was first GPLed I spent some time porting it to GNU libc
from
: libc5.  So I have some experience and familarity with the code.  TWIN is
BIG.
: It aims to provide cross platform win32 ABI and API support.  It would be
a
: huge job to take TWIN and make it appropriate for embedded systems because
it
: is so big.

I'm also quite familiar with the TWIN (and Wine) codebase.  I think TWIN
is about 2.5Mb core requirements, Wine is much larger.



: That said, I suspect that microwindows would benefit greatly if someone
were to
: take the windows controls from TWIN (i.e. buttons, combo boxes, etc) and
make
: them use only win32 calls (no TWIN internals) and make them all work with
: microwindows.

I've been wanting to do this for quite some time.  As you point out, the
TWIN
implementations of the windows standard controls use TWIN internals, and so
does Wine.  I'd been thinking for some time that it would be nice to have
a set of std windows controls that was based solely on Win32, which would
allow
the controls great portability, even to the extent that they could be built
and
tested under windows itself....

Regards,

greg