Port AWT

[dmik]

AWT is a lower level Java GUI toolkit that very closely maps to the underlying OS primitives. Swing is partly based on AWT.

[dmik]

AWT uses DDraw from Odin32 which uses MS COM stuff. The macros for defining COM stuff are defined in Odin both in wine/obj_base.h and in wine/dd_obj_base.h which creates a huge bunch of conflicts. Solving this now. Quite a tricky code (as the whole COM though).

[dmik]

The Odin problem has been fixed in r 21479 there. Moving further.

[dmik]

awt.dll builds after r193. Will test it now.

[dmik]

Tested a bit. It loads, but requires java.awt.image.* for doing anything useful. Working on that.

[dmik]

It was needing mlib_image.dll actually. Built it now. The next is fontmanager.dll.

[dmik]

fontmgr.dll builds now. Moving further.

[dmik]

The FontManager? can't find fonts; working on that.

[dmik]

After supplying a Lucide Sans font manually, I got the first
hello world AWT app working. It however shows instability in various areas (no proper redraw on resize, hang on exit, etc). I will deal with that now. Also, I have to find why Odin doesn't supply system fonts to Java.

[dmik]

Regarding the hang. It's really strange:

command	odin lib	have any PM window open (except FC)?	Result
java -version	Release	No	HANG
java -version	Release	Yes	Works
javac -version	Release	No	Works
javac -version	Release	Yes	HANG
java -version	Debug	No	Works
java -version	Debug	Yes	Works
javac -version	Debug	No	HANG
javac -version	Debug	Yes	Works

100% reproducible. UNI mode. Complete bullshit.

[dmik]

Found the reason for the hang (which is an endless loop in fact). It's the code that walks the DosQuerySysState? structure that I added to properly query already loaded DLLs in LIBPATHSTRICT=T mode (Odin32 would crash before when starting an app in this mode). Looks like the returned structure is sometimes broken...

[dmik]

Great. Now the hang has completely disappeared. Right after I made a lot of debugging. And doesn't appear any more when I revert all. Crap. I don't know how to debug it then. This API is known to be extremely bogus and I must be hitting yet another bug.

One reason for the hang could be that the bogus QSLREC record (see odincrt/dos.cpp for the description of the bug) happens to be the last one in the list, which is indicated by pNextRec set to NULL. And when we work around this bug we correct pNextRec and set it to non-NULL and therefore hide the end of the list from ourselves. If for some reason another record happens to follow this last one in the buffer (they are stored in the buffer not necessarily in the list order), we will get an endless loop.

But I can't check this assumption because it doesn't happen any more. Will try later.

[dmik]

Uggh, found the reason of why closing the AWT frame window doesn't deliver the WINDOW_CLOSING event (and as a result, the hello world application doesn't exit). Somehow the new XP-style SetWindowSubclass?() API in Odin32 is bogus and the WM_CLOSE event (which is a trigger for Java's WINDOW_CLOSING) does not get delivered to AWT.

Switching the Java code to the old subclass API (SetWindowLongPtr?(GWL_WNDPROC)) fixes the WM_CLOSE delivery and also many redraw problems -- I can now press buttons and resize (I get debug assertions in certain places but that's a different story). This switch to the new API (or its active usage) seems to be done after Innotek stopped maintaining its Java port so it may explain why the implementation of the new API is bogus in Odin32.

I created ​http://svn.netlabs.org/odin32/ticket/18 in Odin to track this bug. I will try to fix the assertions first, before fixing this API itself.

[dmik]

After r 21524 in Odin, the debug assertion has gone and our ​Snowman hello-world application now resizes and terminates well.

Tried a simple Swing application. It also seems to work but there is some problem with the font. Apparently Java wrongly takes its metrics so that I get very high letters with zero width (i.e. nothing can be actually seen when typing). Will look at it next.

[dmik]

I finally found why fonts didn't work. It's done really stupid. The font subsystem separately decides if it is OpenJDK or not (though it's already known from e.g. the JVM) by checking the presence of the LucidaSansRegular?.ttf file in the java.home/lib/fonts... If this file is present it assumes it's not OpenJDK, tries to use a proprietary font rasterizer (not available in our sources of course) and silently sets a dummy font scaler on failure that does nothing.

By a funny coincidence, LucidaSansRegular?.ttf was the first font that I copied to the fonts folder in order to stop Java from failing because of the complete absence of any fonts.

Anyway, the next step is to instruct Java to look into OS/2 font directories (e.g. C:\PSFONTS and others, according to user.ini) for fonts so that there is no need to create/maintain the java.home/lib/fonts folder at all.

[dmik]

Forgot to mention that I can run may Swing apps ATM (actually all I tried run, including various demo applications, and even such heavy as Java2DDemo.jar). The only thing is that fonts are ugly now. I have to find how they initialize and use FreeType?. I must say that the font subsystem in AWT (and both AWT and Swing in general) is way too much complex (so many different API layers each with own interfaces, classes, delegates, aggregates and so on), which makes it very difficult to navigate through the code. I actually don't understand why such complexity is necessary at all (looks like the devs wanted to show they are OOP gods instead of providing something simple that just works). OTOH, I now better understand why Java is so heavy and why 3rd party people created SWT :)

[dmik]

Also, when using the debug build, I get the following assertions from time to time:

#  Internal Error (d:/Coding/javaos2/openjdk/hotspot/src/share/vm/runtime/handles.cpp:32), pid=447, tid=29294614
#  Error: assert(SharedSkipVerify || obj->is_oop(),"sanity check")

#  Internal Error (d:/Coding/javaos2/openjdk/hotspot/src/share/vm/runtime/synchronizer.cpp:3440), pid=454, tid=29753367
#  Error: assert(false,"Non-balanced monitor enter/exit!")

I don't fully understand what they really mean (didn't investigate it deeply so far) but this is something for to do in the feature. (Probably not for the beta though).

[dmik]

In r213 I fixed font searching. Now JDK picks up fonts installed in the Font Palette and doesn't need to distribute any fonts with it. This differs from Innotek JDK where fonts installed in the system were completely ignored.

[dmik]

The font stuff is basically done. Note that I had to enable anti-aliasing on OS/2 by default because standard Type1 fonts have bad hinting and look really ugly otherwise. Also, FreeType? doesn't seem to extract (or Java doesn't seem to use) bitmapped versions of glyphs for small font sizes.

Note that this all differs from earlier Innotek ports where a proprietary font rasterizer is used which a) uses bitmapped glyphs correctly and b) gives a slightly different anti-aliasing quality.

[dmik]

Turned out that the broken input of national (non-Latin-1) characters was a complete Odin fault, and quite a difficult one. Fixed it in r 21529 there. Works now.

This ticket may be considered as done now.