View Page Source

This page describes my attempts to run/build things like midp.exe and kvm.exe. Those are from __midp2.0fcs__ and __j2me_cldc-1_1-fcs-src-winunix__ respectively. midp.exe is basically a J2ME emulator that can run midlets just like phones running [https://en.wikipedia.org/wiki/Series_40|Series 40] and similar do. kvm.exe is a virtual machine, designed by Sun to be used on devices with limited resources (hence its specification name).

! Compiling

I managed to build kvm.exe using both cygwin and msvc6. It required installing cygwin along with its make and cmp (difutils) tools (just to make sure I also installed the gcc stuff), and Java Development Kit. Then I added JDK/s and cygwin's bin folders to system {{PATH}} variable the way it's commanded in the docs. To make the build working though, I also had to trick the system to use msvc's link tool by renaming its equivalent in ''cygwin/bin'', link.exe, to link_cyg.exe (a hack that worked so whatever). Lastly, since I installed a later version of JDK, I had to replace {{JAVAC = javac}} with {{JAVAC = javac -source 1.3}} in makefiles in ''D:\kvm\tools\jcc'' and ''D:\kvm\api''

Note: after unzipping the midp and cldc packages to the root dir of my D drive, I renamed them to be ''midp'' and ''kvm'', I pasted entire paths above for simplicity.

For cygwin, I run "[https://support.microsoft.com/en-us/kb/320148|command prompt from here]" in ''D:\kvm\build\win32'' dir and use the command:

> make clean all

The executional is created in ''D:\kvm\kvm\VmWin\build'' dir if you're building with cygwin, and in ''D:\kvm\kvm\VmWin\build\Debug'' if you're building with msvc.

Note that {{nativeFunctionTableWin.c}} and {{ROMjavaWin.c}} are generated by javac that compiles the Java files in jcc dir, so you won't be able to build the msvc project until you execute the makefile in ''D:\kvm\tools\jcc''.

To build midp.exe, I added an {{ALT_BOOTDIR}} variable to system vars with the value of my JDK folder (inside quotes, or the path slashes will be killed by jcc). Line 159 of ''D:\midp\build\share\makefiles\Defs.gmk'' should be replaced with {{JAVAC = $(BOOTDIR)/bin/javac$(EXE) -source 1.3}}. You also need zip and unzip tools installed for cygwin. After building most of the files, the cp tool will fail to copy gifs from ''D:\midp2.0fcs\src\example\icons'', since there're only pngs there. Remove line 354 from ''D:\midp2.0fcs\build\share\makefiles\Example.gmk''.

Note: if one is compiling midp against cldc 1.1 (the intended version is cldc 1.0.4, but it's missing float functions used by many games), it's gonna have compilation errors with com.sun.cldc.io.GeneralBase. To enable cldc 1.1 support, run this patch prior to renaming of the dir: https://gist.github.com/vadosnaprimer/53cd13f00ef32167fea8d3370ca9f3f5 That doesn't magically make the previously incompatible games work though, one will have to debug the problems anyway.

To build midp.exe, I also used

> make clean all

from ''D:\midp\build\win32\kvm''. The file spawned in ''D:\midp\build\win32\kvm\bin''.

How other people did it:

https://phonej2me.github.io/recompiling_midp/recompiling_midp.html

! GCC

From how building goes - msvc's cl and link are the only setup that works - one can make a justified assumption, that no one even attempted to compile it for windows with gcc. It lacks basic preprocessor definitions accounting for gcc, and it breaks when building with cygwin's tools for win32.

After tweaking the sources to compile with gcc, it segfaults right at the start. {{debug}} target affects the place where it happens, but I can't seem to be able to resolve it.

! VisualGDB

It seems it's the only way to import the project properly to MSVC, and configuring the project to use the cl/link path during compiling results in a solution buildable from MSVC. (Well, it can be imported from a .pdb file using an extension to VC11+, but it won't compile.) Configuring means adding include/lib directories, setting up the project type (gnu makefile), and other stuff.

The default toolchain there is gcc/gdb though, so they should be ignored by not using a {{GCC=true}} flag in the {{make}} command, but using {{DEBUG=true}}. It makes cl create a symbols file.

In the MSVC's Debugging properties of a project, one must add a command to launch the generated executional, instead of going the default way. So you could use Visual Studio debugger without the need to attach to a running process. Arguments to run an installed midlet for some reason don't work. But it can be launched via GUI anyway.

! License

In case you're wondering, Sun Community Source License isn't strictly open source, but it allows editing the source and distributing the compiled executional for the sake of research.

http://www.oracle.com/technetwork/java/scsl-1-1-149938.txt

Research Use License:  (i) use, reproduce and __modify the Original Code__, Upgraded Code and Specifications to create Modifications and Reformatted Specifications for Research Use by You, (ii) __publish and display Original Code__, Upgraded Code and Specifications with, or __as part of Modifications__, as permitted under Section 3.1 b) below, (iii) reproduce and distribute copies of Original Code and Upgraded Code to Licensees and students for Research Use by You, (iv) compile, reproduce and distribute Original Code and Upgraded Code in Executable form, and Reformatted Specifications to anyone for Research Use by You.

"Research Use" means use and distribution of Covered Code only for Your research, development, educational or personal and individual use, and expressly excludes Internal Deployment Use and Commercial Use.

"Covered Code" means the Original Code, Upgraded Code, Modifications, or any combination thereof.

"Modification(s)" means (i) any change to Covered Code; (ii) any new file or other representation of computer program statements that contains any portion of Covered Code; and/or (iii) any new Source Code implementing any portion of the Specifications.

! Notes to self

InitializeWindowSystem()