RE: input line is too long

["Erik Poupaert" <erik dot poupaert at chello dot be>]

Hi

About getting rid of swt-win32-2122.dll and integrating it into the
executable.

I know I've got a valid libswtwin32.a, built from (slightly modified)
sources, but equivalent to swt.jar. It works with the dll present. So, I get
rid of the loadLibrary calls in the sources (Library.java) and rebuild it.
By the way, the changes to the swt java sources concern in the first place
the fact that jikes/javac thinks a "short" and a "char" don't need to be
cast to each other, while gcj will extort an explicit cast from you. I don't
know who's right. And then there is another thing about a method returning
void, that should return a boolean according to the one compiler, while the
other just lets go ... Bah.

First snag. The native swt sources, i.e., callback.c, structs.c, swt.c, and
swtole.c only compile and build with VC.NET. I've tried with VC6, but it
explodes in every direction. The same for gcc. I can only compile callback.c
with gcc. All the other sources contain things unknown to the gcc *.a files.
It's primarily about stuff like 'CHEVRONREBAR' and what have you...  By the
way, I can't find a corresponding liboleacc.a anywhere, mentioned in the
VC.NET makefile. It still exists in ancient repositories cached in Google,
but the original servers themselves have disappeared from the face of the
internet. But then again, liboleacc.a seems to supply nada symbols anyway.

When I try to compile:

gcj -fCLASSPATH=cls HelloWorld1.java libswtwin32.a  *.obj -o
hello.exe --main=HelloWorld1 -lole32 -lcomctl32 -luser32 -lgdi32 -lcomdlg32 
-lkernel32 -lshell32 -ladvapi32 -limm32 -lwinspool -loleaut32

At first at get:

Info: resolving __iob by linking to __imp___iob (auto-import)
callback.obj(.text+0x21d):callback.c: variable '_iob' can't be
auto-imported. Please read the documentation for ld's
 --enable-auto-import for details.

Then, I stick a truly ugly and unproven piece of duct tape to it: I
recompile callback.c only, with gcc, and substitute it for the VC.NET
compiled object. Then ld stops complaining.

>hello
Exception in thread "main" java.lang.UnsatisfiedLinkError: GetVersionExW

Now, GetVersionExW is defined in kernel32.dll; which should have been
linked. Therefore, I'm sure I must have missed something essential
somewhere. Does anybody have an idea what it could be?