Friday, September 18, 2009

Single to Dual/Multi Core with Windows XP (ACPI HAL)


Sometimes, people have the problem that their Windows XP is running as a “single core” system, only, although there are two or more cores installed. This can usually be seen in the task manager, where performance shows only a single graph, although “one diagram per CPU” is selected.
I talk about cores here, the same applies to multiple processors. Those are usually used on servers, though, where few people would start “fixing” the HAL.

Hardware Abstraction Layer – HAL

The reason is usually, that the normal ACPI HAL (Hardware Abstraction Layer) has been installed which does not support more than one core. In theory, XP recognises when a new CPU is installed, re-checks, and installs the correct hal. This does not always work, though.
The usual HALs are
  • Standard PC
  • ACPI Uni-Processor (UP)
  • ACPI Multi-Processor (MP)
  • MPS Multi-Processor (APIC)
Especially in the context of virtual machines running under SUN VirtualBox, this does not work. When a windows XP system is installed with only one core active, and more core(s) is/are added later on, the CPU “id” does not change … no redetection is done, the other cores are not recognised. Another reason may be that the “ACPI PC” is not the same as “ACPI UP”, and only ACPI UP is able to support, and thus detect, more than one CPU. In the case of VirtualBox, the situation may also be caused on the IO-APIC not being enabled on install. According to SUN, XP Uniprocessor with IO-APIC is slower than without.
Officially, there is no way to upgrade the HAL. You can downgrade it, though, which is not a good idea … there is no way back.

Using devcon.exe: Forced HAL Upgrade

I found a very interesting post about the “devcon.exe”, a tool provided by MS as “the command line version of the device manager”, and its application to the HAL switch problem.
The important stuff:
Just execute the following commands in a cmd.exe shell …
devcon sethwid @ROOT\ACPI_HAL\0000 := +acpiapic_mp !acpiapic_up
devcon update c:\windows\inf\hal.inf acpiapic_mp

Of course, this may completely break your system. Make backups, find out beforehand how to restore, etc. Using a virtual box system, this is easy, just make a snapshot and restore if the upgrade does not work.
After running devcon, you reboot the system; after the reboot, XP re-detects all hardware, and the requests another reboot. This may change some of the hardware names, especially the LAN connection may get the number 2.

Hidden Devices

You can use the show-hidden trick of the device manager to display the old devices and remove them:
set devmgr_show_nonpresent_devices=1
start devmgmt.msc

Switching the HAL

Once you get a ACPI MP hal, you can switch it to whatever you like using the device manager. Just select “new driver” for the “Computer” device.

Doing it manually

Before I found the post by “hedrums” above, I tried to do it manually. Interestingly, none of the files is locked by windows. They are loaded so early and completely in the boot process that they are no longer “needed” (used) in a running system, and can just be replaced.Yet, I never managed to copy and rename the files correctly.
Afterwards, by comparing the file sizes between the used versions (in system32) and the restore/backup versions (in ServicePackFiles\i386), I recognised the following:
• ntoskrnl.exe == ntkrnlmp.exe (2,04MB)
• ntkrnlpa.exe == ntkrpamp.exe (1,93MB)
• hal.dll == halmacpi.dll (131kB)
So, by copying the three files ntkrnlmp.exe, ntkrnlmp.exe and halmacpi.dll to system32 and renaming them to ntoskrnl.exe, ntkrnlpa.exe and hal.dll, respectively, you may be running an ACPI MP hal. I have not tried this, though.
Alternatively, using the correct ACPI UP files (whichever they are), you may get a UP system that, in turn, is automatically able to detect the multicore and again, install the correct drivers …


I now found a tool that does the same stuff, a bit more comfortable:

Saturday, September 12, 2009

Ubuntu Display Manager

Just some notes about the display manager(s) on Ubuntu I found out over time, and about their startup settings.
The display manager – that’s usually gdm, the gnome d.m.; alternatively kdm on kubuntu/kde, or even the good old xdm when using a lightweight desktop. In any case, it’s usually started to show a user login screen ;)

Text mode

It is often practical to boot into text only mode – at least, when you know a bit about linux. I’m not talking about removing gdm forever (apt-get remove gdm or update-rc.d -f gdm remove do this), but to use text mode in certain situations – including when you know your Xorg or gdm setup to be broken. Or, when you really want to save battery power ;)
The gdm startup allows this by putting text into the kernel command line. If this parameter is found, /etc/init.d/gdm just exits again. This can be achieved by:
  • stop the bootup in the grub menu, then

    • press “e” to edit the wanted entry
    • use the cursor keys to select the “kernel” line
    • press “e” again to edit the line
    • go to the end of the line and add “text”
    • press return to leave the line editing
    • press “b” to boot the edited entry
  • create a grub entry for text mode

    • sudo gedit /boot/grub/menu.lst
    • copy the first real boot entry (that starts with “title”) into another one below
    • change the title – append “text mode” or such
    • add “text” to the end of the “kernel” line
    • next time you boot the system, you can select the text mode and have tun.
This also disallows to start the gdm via the init script later on, because the entry is part of the kernel command line that cannot be changed. Yet, starting gdm directly achieves the same result.
By the way: I have not hardly anything about this on the web. Of course, you just need to look into /etc/init.d/gdm … the only post I found referring to this is

gdm, kdm and xdm

Ever wondered how the various display managers that can be installed on (k)ubuntu stay out of each others hair?
  • each of them may be added to the runlevels
  • when starting, they each check whether they are the “preferred display manager” via /etc/defaults
  • if no, they exit; if yes, the one that should starts.
This way, it should not be possible to start more than one display manager – which you usually don’t want to. Opensuse, on the other hand, uses just one rc-script which decides which dm to start.


As a side note – I never know how to edit the /etc/rc.d?/scripts. This changed over time, mainly because of the linux standard base (LSB), I believe. The current command-line tool is update-rc.d which is not really nice to use.
But, the package sysv-rc-conf contains a textmode ui tool of the same name which seems to be usable, at least.

There is also chkconfig and insserv as I know from opensuse; yet, their packages refuse to install on Jaunty due to some sysv-init package conflicts. Probably because ubuntu migrated from sysvutils to sysvinit-utils. Or rather to upstart, where sysvinit-utils only contains some utilities.

Webservices with Axis2/Java - the simple POJO way

There are many ways to create web services in Java; the most common implementation, nowadays, is using Apache Axis2/Java and a servlet container such as Apache Tomcat or Jetty.
On the Axis2 web site, there are a number of tutorials and explanations of the various concepts; yet, somehow, I'm missing a description of the "most easy way" of creating a web service. That's why I write it here. The tutorials are based on using the provided build.xml files instead of explaining how to do it. This makes it very hard to work in a different context.

A POJO in an .aar

Axis2 is able to "interpret" any Plain Old Java Object (POJO) as a web service, given the right hints. A Pojo is just a java class with some public method(s).


public class Echo {
public String echo(String input) {
return input;

To tell Axis2 that this is a web service, you need additionally

  • a services.xml that defines this class as a POJO RPC web service
  • an echo.aar that contains (at least) the services.xml in the META-INF directory, and usually, the web service code (.class file(s)).


<service name="Echo" scope="application" >
Tecbites Echo POJO web service
<messageReceiver mep=""
<messageReceiver mep=""
<parameter name="ServiceClass"></parameter>

Put this file into META-INF. 

creating an .aar - jar

One way to create an .aar is just using the jar-tool that is part of the JDK. Using the following folder structure:

, a jar can just be created that is named echo.aar. Check that the jar/aar does not contain the files in a subdirectory named echo!.
javac tecbites/ws/
jar cf echo.aar .

creating an .aar - build.xml

Another way of creating an .aar is using build.xml, the same as creating any other .jar. See the following example:

<?xml version="1.0" encoding="UTF-8"?>
<project name="tecbites.echo" default="aar" basedir="."> <target name="build">
<javac debug="true" srcdir="." destdir="." failonerror="true" />
</target> <target name="aar" depends="build">
<property name="aar" value="echo.aar"/>
<delete file="${aar}" failonerror="false"/>
<jar destfile="${aar}">
<attribute name="Built-By" value="Tecbites"/>
<fileset dir="." >
<include name="**/*.class" />
<include name="META-INF/**" />

Just run ant. You have got ant installed, have you?


The installation of an Axis2 webapp and the deployment of an .aar is explained quite well on the site. Just a short version here, based on Tomcat6:

  • download the Axis2 webapp
  • deploy (copy) the axis2.war into webapps/ of a servlet container (tomcat, jetty, jboss, glassfish, ...)
And start the servlet container. Then, copy the echo.aar into the webapps/axis2/WEB-INF/services directory (the servlet container should automatically unpack axis2.war into axis2/
If you need additional jars or java code you don't want to pack into the .aar itself, there is space in axis2/WEB-INF/lib (for the jars) and axis2/WEB-INF/classes (for any package/name/Class.class files).
Usually, Axis2 is configured for "hot deployment". This means that any .aar copied newly into the services directory of a running server is directly deployed as a new web service. There is also "hot update" which is usually disabled, but can be enabled in axis2/WEB-INF/conf/axis2.xml. Then, the .aars are automagically reloaded when replaced. Of course, any code in lib/ or classes/ is not.
By the way - it should also be possible to deploy the web service by copying the unjared folder structure into a subdirectory of the services dir, thus creating webapps/axis2/WEB-INF/services/Echo/META-INF/services.xml etc.


The web service should then be visible on http://localhost:8080/axis2/services/listServices (replace port 8080 with the correct one of your servlet container installation). There, you can see all deployed services and list their methods.
The WSDL can be accessed via http://localhost:8080/axis2/services/EchoService?wsdl.
Axis2 supports a part of REST, named POX - Plain Old XML documents over http. This allows to call the web service via http://localhost:8080/axis2/services/EchoService/echo?input=Good%20Morning. A web page should be returned reading

<ns:echoResponse xmlns:ns="http://ws.tecbites">
<ns:return>Good Morning</ns:return>

By the way - the following error message when accessing http://localhost:8080/axis2/services/EchoService means the service is working correctly: ;)

<soapenv:Text xml:lang="en-US">
The endpoint reference (EPR) for the Operation not found
is /axis2/services/EchoService and the WSA Action = null

Direct POJO deployment

There is also the description of deploying the POJO .class file directly into a specially configured axis2 directory. In the axis2/WEB-INF/conf/axis2.xml, there is usually a line reading

<!--POJO deployer , this will alow users to drop .class 
file and make that into a service-->
<deployer extension=".class" directory="pojo"

This should allow to deploy the ws by copying tecbites/ws/Echo.class into the pojo directory. In the context of the jetty servlet container inside the Global Sensor Networks (GSN) project, I was unable to get this to run.

JAXWS @WebService annotations

The JAXWS standard allows to "create" web services by annotating the class with the @WebService tag. In the axis2+service.xml context, this is not necessary, but supported.
Yet, this is helpful when the web service class contains public methods that should not be accessible as web service methods.

import javax.jws.WebService;
import javax.jws.WebMethod;

public class Echo {
public String echo(String input) {
return input;
public /*static*/ String helper(String input) { return input; }

Side note

You might think I'm working for the Apache project, the way I propose their products/projects here. No, I'm not, it's just a fact that "they" are developing open source Java projects for many purposes, from development support (log4j, ant, ...) over utilities (commons, ...) to enterprise technologies (tomcat, axis2).

Eclipse Galileo 3.5.0 as packages for Ubuntu Jaunty


The eclipse packages delivered with ubuntu are usually very, very old (3.2.x on jaunty). This is mainly due to the rule of debian that everything(!) needs to be compiled by the maintainers. Also, they use a completely different Java compile setup than the eclipse developers - gcj (which is really open source) instead of Sun JDK.
I just found someone who maintains the eclipse-provided binaries as a set of packages for ubuntu jaunty.
Quite easy to install and use - just note that the JEE tools are inside eclipse-wtp (web tools project).
It may be that there is stability problem ... I had one crash so far ... no idea whether this was related to the packages or the Java setup itself on my system (it was somewhere in the subversion->libsvnjavahl->libapr stuff).