nanogui: Thread: Kaffe port

: > As I see Win32 Kaffe port just uses CreateWindowEx() with 
: > "LISTBOX" or "BUTTON"
: > classes etc.
: > How can I implement such a functionality of CreateWindowEx() 
: > on Microwindows?
: 
: Don't implement them.
: In fact, in the win32 dir of Kaffe, just don't use the files that are for
: ListBox, ListEdit, Buttons, etc... 
: See in the X11 dir which files are there. You only need to implement the
: files you find in the X11 dir AND in the win32 dir.
: -jec

I have implemented BUTTON, but not listbox, yet.  As Jean-Eric says,
though, you don't need to implement any of them.  (Jean-Eric,
I think we should post the last tarball of what you created, so that
at least Roman can see what you did without having to start from scratch.)

Regards,

Greg

>From: "Roman Guseynov" ####@####.####
>To: ####@####.####
>Subject: Re: Kaffe port
>Date: Mon, 22 May 2000 14:22:28 +0300
>
>Hi, Jean-Eric
>
>I need JVM on MWin anyways and I think I'll port Kaffe (what else?).

Roman,

Kaffe is a nice VM with lots of features, but for most embedded
systems, it has a huge footprint.

I came across this small Java VM, that might a little better
for small embedded devices:

http://www.crazyrobots.com/tinyvmsite/

Regards, Rosimildo.


________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

> Roman,
> 
> Kaffe is a nice VM with lots of features, but for most embedded
> systems, it has a huge footprint.
> 
> I came across this small Java VM, that might a little better
> for small embedded devices:
> 
> http://www.crazyrobots.com/tinyvmsite/

Seems interesting. All depends on what you plan to do with your JVM. Kaffe
is a FULL JVM with all the 1.1 things and some of the 1.2.

If you go with tinyVM, ok, but be careful with the license. It's not on
their website, so you'd better check before beginning.

And NO, Kaffe has not a BIG footprint. If you compile it as is (1.0.5) with
all the modules, it's ~4Mb, but when you begin removing parts (some IO, net,
...), you can have a little JVM in ~100Kb! (from Tim (Kaffe developer) )

Bye
-jec

On Tue, 23 May 2000, Jean-Eric Cuendet wrote:
> If you go with tinyVM, ok, but be careful with the license. It's not on
> their website, so you'd better check before beginning.

From the documentation:

-------------------------------------------------------------

About the License
-----------------

I'm releasing under the Mozilla Public License (see LICENSE)
for now, since librcx is under that same license, and TinyVM
is linked against -lrcx. TinyVM is copyright (c) 2000 Jose
Solorzano.

-------------------------------------------------------------

However, it's a quite limited (no GC for example) embedded VM which fits
in about 10KB of RAM on a H8 microcontroller. It's debatable how easy it
would be to port to a more general purpose processor/OS, and in any case
it doesn't have any support for a GUI (which presumably you want if you
are intending to use it with NanoGUI or Microwindows).

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

: It's debatable how easy it
: would be to port to a more general purpose processor/OS, and in any case
: it doesn't have any support for a GUI (which presumably you want if you
: are intending to use it with NanoGUI or Microwindows).

I read through most of the source code last night.  It's actually quite
well written, and (obviously) simple.  It would easily port to a system
like Microwindows, but, as Alex says, you'd need to bring along Kaffe's
AWT or something similar in order to get something done graphically.
However, even if this were done, the JVM would start needed extending
because currently it's arrays are limited to 255, for instance.

However, I got excited about the LegoMindshare stuff, and I think
I'm going to go build a robot...

Regards,

Greg

> For the porting, the code I wrote is of no help to you.
> Use the existing win32 code and add some #ifdef UNDER_MWIN when necessary
> (not a lot of place).
> Don't define UNDER_95 nor UNDER_CE but only UNDER_MWIN and compile.

What the reason of using win32 code?
Maybe it is more convinient to change clib/awt/X/* of Kaffe instead of
clib/awt/win32/* ?
Then I should only "remap" Xlib calls to Gr* MWin calls (of course also doing
other things).
I mean do not use any win32 code while porting.
Is it right way?

Regards,
- Roman

---------------------- Forwarded by Roman Guseynov/R&D Ukraine on 24.05.2000
15:57 ---------------------------


Jean-Eric Cuendet ####@####.#### on 24.05.2000 14:57:21

To:   Roman Guseynov/R&D Ukraine@R&D Ukraine
cc:
Subject:  RE: Kaffe port





> > Don't define UNDER_95 nor UNDER_CE but only UNDER_MWIN and compile.
>
> What the reason of using win32 code?
> Maybe it is more convinient to change clib/awt/X/* of Kaffe instead of
> clib/awt/win32/* ?

See with Greg, but AFAIK, win32 layer is more  advanced than the Xlib one.

> Then I should only "remap" Xlib calls to Gr* MWin calls (of
> course also doing
> other things).
> I mean do not use any win32 code while porting.
> Is it right way?

If you know X better than win32 and if X layer in MWin is usable, it's OK!
-jec

: > What the reason of using win32 code?
: > Maybe it is more convinient to change clib/awt/X/* of Kaffe instead of
: > clib/awt/win32/* ?
: 
: See with Greg, but AFAIK, win32 layer is more  advanced than the Xlib one.
: 
: > Then I should only "remap" Xlib calls to Gr* MWin calls (of
: > course also doing
: > other things).
: > I mean do not use any win32 code while porting.
: > Is it right way?
: 
: If you know X better than win32 and if X layer in MWin is usable, it's OK!

I suggested that the Win32 version be used first, since it is currently
a bit more advanced than the Nano-X api, and it's exact, so there
aren't changes that need to be made to each API call.

However, it may be better to use the Nano-X api, since it allows multiple
processes to connect with the server.  It just depends on how Kaffe is
to be used, in side another process or more standalone.

I'm going to be spending the next few weeks concentrating on getting
the Nano-X api up to speed for the multiple widget set ports underway.

Regards,

Greg

Hi all,

I see it is easier to use Win32 API to port Kaffe to MWin. At least I should try
it before playing with nano-X an X APIs.
Howewer I don't know how to get some functions working under MWin. There are:
- optional:
     RegisterWindowMessage()
- necessary:
     PostThreadMessage()
     GetCurrentThreadId()
     GetTextExtentExPoint()
     GetKeyState()
     GetKeyboardState()
     ToAscii()

Also, Jean-Eric, could you give me some tips about modifying Kaffe's configure
script to make it compiling Win32 sources under linux.
I copied all the sources from .../libraries/clib/awt/win32 to
.../libraries/clib\awt\mwin and leaved only these:
cbd.cpp
clr.cpp
cmnwnd.cpp
cmnwnd.hpp
evt.cpp
fnt.cpp
gra.cpp
img.cpp
imggif.cpp
imgjpeg.cpp
imgpng.cpp
tlk.cpp
tlkprops.hpp
toolkit.hpp
widget.cpp
wnd.cpp

I'll appreciate any help concerning this stuff.

Regards,
- Roman

: I see it is easier to use Win32 API to port Kaffe to MWin. At least I
should try
: it before playing with nano-X an X APIs.

I agree


: Howewer I don't know how to get some functions working under MWin. There
are:
: - optional:
:      RegisterWindowMessage()

RegisterWindowMessage isn't optional.  It must return a new message
number.  I have it faked up something like the following:

UINT WINAPI RegisterWindowMessage(LPCTCSTR lpsz)
{
    static UINT msg = 0xc000;
    return msg++;
}


: - necessary:
:      PostThreadMessage()

I think I implemented this also.  Basically it needs to call
PostAppMessage(), or perhaps PostMessage with a NULL
hwnd.


:      GetCurrentThreadId()

This can be dummied up to return a constant value.


:      GetTextExtentExPoint()
:      GetKeyState()
:      GetKeyboardState()
:      ToAscii()

The kbd support is still not done, these can be commented
out or implemented as null procedures.

There is one other major issue:  Microwindows has a main()
and so does Kaffe.  Look at Microwindows' main()
in src/mwin/winmain.c and make sure that Microwindows
is init'd from Kaffe somewhere; otherwise, it definitely won't
run.

Perhaps I should post my tree somewhere.

Regards,

Greg