[webkit-dev] JavaScriptCore Windows port technical info

[Krzysztof Kowalczyk]

I've a Windows port of JavaScriptCore more or less running on my
machine. I'll make the sources available in the next day or two for
interested parties. This e-mail describes my approach, problems I've
encountered and is meant to start a conversation on what would be the
best way to integrate this port with mainline sources.

1. For building I've wrote a Makefile.vc makefile. Building is from
command line. I was able to build it with Visual Studio 2003 and VS
2005 Beta 2. Failed to compile with VC6 (too many unsupported
constructs). Should also work with the free command-line tools that
Microsoft provides (basically the compilers without the IDE).

The advantage of makefile vs. project files is that only one makefile
should work for many compiler versions. The advantage of project files
is that windows developer are much more used to developping in an IDE.

2. Windows doesn't ship with ICU so I had to download pre-built ICU
dll. They're quite large. I think the overall goal should be to make
the build self-contained so it would be good if those pre-built dll's
were also stored in CVS.

Another option I was thinking about was statically linking with ICU.
The dlls are really big and I'm not sure how much of this code is
really used (it looks like jsc only links to toupper/tolower
functions, but that might still bring the whole unicode data set). My
ultimate goal would be to have this code running on Pocket
PC/Smartphone devices where (small) size matters.

Also, ICU headers in CVS have stripped windows-related code so I had
to use the headers from "official" ICU download.

3. Generating grammar files is possible (using windows port of bison)
but not easy for a windows programmer. It would be good if
pre-generated files were part of cvs (could be in windows-only
directory, so that it doesn't pollute the main code).

4. I hand-generated the *.lut.h files and the pcre chartable.c file
although it would be fairly easy to add makefile target to do it
automatically.

5. I've chosen #ifdef WIN32 as the switch for windows-specific code

6. Currently it only builds as a static library. Building a DLL is a
problem. Unlike on Unix, by default symbols are not exported by a DLL.
In order to have a given symbol exported in a DLL, it either has to be
added to *.def file or prepended with a special __dllspec(export)
syntax. A solution that e.g. curl uses is to define EXPORT macro that
is empty for unix and __dllspec(export) for Win. The problem with that
is that it pollutes the sources. But I'm not sure if the alternative,
i.e. manually creating *.def file, is realistic due to the number of
functions that need to be exported (I assume that it's a big number,
but I might be wrong).

7. I've discovered 2 bugs that are not win-specific
(http://bugzilla.opendarwin.org/show_bug.cgi?id=4546 and
http://bugzilla.opendarwin.org/show_bug.cgi?id=4548)

8. I've created JavaScriptCore\os-win32 directory to hold win-specific
files. So far it only has the minimal stdint.h implementation. Other
than that it's just #ifdef'ing here and there to cover superficial
differences.

I'll try to submit bugs with patches for those issues although in
order to have the the thing built, they all have to go.

I welcome comments and ideas, especially on #6, how to make building
as a DLL possible.

-- kjk