Canmore's Blog

Yesterday, I stumbled over an interesting problem with Wine: If a ServerName directive exists in /usr/local/etc/cups/client.conf, i.e., if you are connecting to a shared server for printing services, programs started with Wine seem to hang.

This problem is caused by non-reachable servers. It might occur when you change your network or when the shared server is unavailable. In this case, Wine will seem to hang. More precisely: If you wait long enough, the application will run eventually. But nobody likes waiting very much.

So, if you have a similar problem, abort the "hanging" application and check the console output. My output contained the line

module:attach_process_dlls "winspool.drv" failed to initialize, aborting

and to solve the problem, I simply changed client.conf by adding

ServerName localhost

in the first line and restarting CUPS via /usr/local/etc/rc.d/cupsd restart.

Since the blog seems to be the entry point for most of my visitors, it makes sense to announce new content. Be it hereby known that there is a new HOWTO online. It explains how to use the Microsoft Windows 7 boot manager to boot FreeBSD.

Enjoy.

By pure chance, I stumbled over a true gem for all programming related to computer graphics: GLT ZPR, a mouse manipulation module for C or C++ GLUT/OpenGL programs (verbatim quote).

The module is very easy to use: Simply #include "zpr.h" and call zprInit(); after you called glutCreateWindow and have made your local initializations (i.e. special setup for the window etc.). Now you are able to use the left, right, and middle mouse buttons to rotate, pan, and zoom—just make sure that your GL_MODELVIEW matrix is not reset.

You can download the program from Nigel Stewart's homepage (I am not linking directly to the sources because I do not want to be impolite). By the way: It is also possible to specify selection and pick functions, but I have not tried this functionality yet.

If you cannot trust your local network for some reason, SSH tunneling can help you. All you need is:

• A machine outside your current local network, for example a server with a static IP address in some data centre.
• ssh (on your local machine)
• A proxy server (on the remote machine)

My remote machine runs Debian, and I decided to install tinyproxy, a tiny HTTP proxy server. Configuration is done quickly by adding the following lines to /etc/tinyproxy/tinyproxy.conf:

	Port 	8888
	Listen  127.0.0.1

I would recommend commenting out any other Listen lines. Assuming you do not want to run an open proxy, you only want tinyproxy to listen locally. After editing the configuration file, restart the proxy via /etc/init.d/tinyproxy restart.

On your local machine, execute the following command:

	ssh user@server.example.net -L 1234:localhost:8888 -N

This forwards all traffic from your local port 1234 to the remote machine's port 8888 (localhost is needed because we configured the server to listen only to the loopback interface), which is where tinyproxy waits for inputs.

You may now tell your cool browser to use localhost:1234 as a proxy server—congratulations, your web traffic is now securely tunnelled to your remote machine.

Addendum: In the command string from above, you can also use -f to request ssh to go into the background.

The search phrases sap platin-gui freezes and use sapgui for java frequently appear in my server log files. However, as I used these in a different context, people will be disappointed once they discover that there are no articles concerning SAP GUI for Java except an installation guide for FreeBSD. This is obviously a matter of some importance, judging from the page hits, so I decided to do my part in the great struggle for bug-free software.

Using SAP GUI for Java

Let me answer the second search string first: Yes, you should use SAP GUI for Java. It is stable, secure and fast. SAP only lists a fraction of all Linux distributions in their Lifetime and Support Matrix for SAP GUI for Java. This is to ensure the highest standards of quality (in translation: SAP does not want to get sued into oblivion and must check that it really, really works at least with some operating systems. It not easy, given the myriad of system environments out there in the wild).

However, in almost all cases, SAP GUI for Java should run just fine under your personal Linux distribution of choice. So, on to the installation:

1. Download a recent Java Runtime Environment from Sun.
2. Download a recent version of SAP GUI for Java. Pick the jar-file that fits your operating system best.
3. Start the installation via java -jar PlatinGUI-Linux-710r9.jar (or execute the jar-file using another method of your choice).

You are done.

Solving problems with SAP GUI for Java

There are several things to do when the GUI freezes or hangs.

• Execute SAP GUI for Java from a terminal emulator. Use xterm or the likes. This allows you to view any error messages that might help to pinpoint problems within the source code.
• Try a different Java Runtime Environment. Install an older JRE (there is no need to remove the current one). Set the PLATIN_JAVA environment variable to the installation directory of the older JRE, for example by executing export PLATIN_JAVA=/usr/local/Java/jre1.6.0_11/bin/java and /opt/SAPClients/SAPGUI710rev9/bin/guilogon from a terminal.
• Try a different version of SAP GUI for Java. It is possible to install different versions in parallel. I would recommend this option especially if you are testing a new version for deployment.
• Check with a supported operating system. Take a look at the Lifetime and Support Matrix for SAP GUI for Java and set up a test environment. This should be your last resort, because in most cases, the problem does not depend on your operating system.
• Take a stack trace. If the GUI hangs, follow this very helpful article and create a stack trace. This diagnostical information is very helpful for SAP's support teams.

Reporting problems

In any case: You should always report your problems. SAP is very grateful for any feedback, even if it is in the form of debug information. You can use one of the following means of communication:

• Use the SDN Expert Forums (free registration required, section "Application Server—SAP GUI", for lesser problems, general questions or if you do not have an account for the SAP Service Marketplace.
• Create a bug report at SAP. Use BC-FES-JAV as the component.

Whatever you do, try to describe the problem as precisely as possible: Attach all debug information (stack traces, error messages etc.) and create a step-by-step reproduction scenario. The more information you provide, the less time your request will take.

This is, for example, a bad bug report:

hello, i get error in gui. please advise!

Whereas this is definitely better (of course, a step-by-step description would be best. System information is also not included, but at least, one could try to reproduce the problem now):

When I click the "delete world" button in transaction GOD, SAP GUI for Java throws a java.lang.NullPointerException. The operation will then be aborted.

Small disclaimer (thereby fulfilling SAP's guidelines for blogging): While I work at SAP, these opinions are my own. Especially the policy regarding unsupported operating systems.

Almost every person I know has an IM account. Most of them are still regular users of ICQ, despite of all its shortcomings. I do not want to make any boring, technical comparisons between the two protocols. Jabber/XMPP is clearly superior to ICQ for a many reasons. However, game theory shows us that "superior product" does not imply "market dominance". Let me try to convince you to create a Jabber account. Here are some questions you might have.

Where can I get a suitable client?

Wikipedia to the rescue! My short suggestions: Use Pidgin (Windows, Linux, BSD) or Adium (MacOS X).

Why should I want to use another protocol?

Because you will need it, eventually. Chances are, you already use a multiprotocol messenger, such as Trillian Pro or Miranda for Windows, Pidgin or Kopete for Linux/Unix, Adium or iChat for MacOS X. If you are not yet using a multiprotocol messenger, you should consider using one. It makes life easier, because you can still maintain your ICQ account (I am doing this, for example, because there are some people who simply refuse to use anything but ICQ. You are not one of them *handwave*).

You should also think about this: ICQ is owned by AOL. They want to make money—which is OK, I suppose. Hence, the original client for the ICQ network is Adware. Of course, AOL does not want you to use any other client:

[…] You agree not to (1) create or use any software other than the Software provided by ICQ or by America Online, Inc., or any affiliate thereof, to enter your ICQ number and password or to access the ICQ Services, without the express written authorization of ICQ; […]

Indeed, AOL changed the protocol several times in the past, thereby kicking out users that did not use the original client. Do you really want to be a part of that? There is also the "default argument" against ICQ, citing their user policy. Basically, AOL owns the right to use your messages for all purposes (see the Wikipedia article for more details). Most people will probably respond to that along the lines of "My conversations are not that relevant". That may be true, but for me, this passage reeks of intolerable business practices.

Alright, stop. How do I get an account?

Good news first: You will not have to memorize a wimpy UIN. Instead, you will get a nice address of the form nickname@server.tld (this also leads to less SPAM in your messenger).

If you happen to have a Google Mail account, you can use Google Talk. This means that people can contact you using your e-mail address. Google has instructions for some clients on their web page.

In any other case, you must decide about a server. You probably want to use either jabber.org. There are of course others, such as jabber.ccc.de. For simplicity, I am describing the steps for jabber.org. I trust you will be able to read the necessary documents for other servers.

• Register an account using the web interface of jabber.org.
• Start the appropriate wizard in your client program that allows you to add a new account. If you do not know how to do this, the documentation could be helpful. The steps for Google Talk might also prove useful (of course, the account details will have to be changed).
• Enter your nickname (nickname@jabber.org) and your password. For security, you should enable SSL/TLS, if that is an option in your client.

Are there any alternatives to using two protocols?

Yes, there is at least one: Jabber transports. Some servers allow you to treat contacts from other IM networks as normal Jabber contacts and "transport" your messages transparently to the other network. Since the server needs to support it, it might not be available everywhere. This little article does not cover transports, so you have to ask a search engine of your choice. Sorry.

Done. What now?

See, that was not so hard.

If you want so, you may now drop me a note via Jabber (canmore@jabber.org). Do not forget to convert your friends, for they, too, shall bask in the glory of Jabber!

Tired of all the fuss about Web 2.0, I decided to proudly announce Web 3.1459..., also known as Web Pi or Web π. Web 3.14159... is clearly superior to Web 2.0 for many reasons (i.e. because I say so).

More information about Web 3.14159... is available on a site that does not use JavaScript or Flash, but simply delivers its content.

If you want to show your support for Web 3.14159..., simply download one of the graphical logos (or design your own) and let your visitors know how hip you are. Domain owners might also create an appropriate subdomain and host some information about Web 3.14159... there.

If you like this idea, spread it around the intertubes and link directly to http://web3.14159.annwfn.net.

I finally released some old code I wrote for a University course. You can find it in the University section of my homepage. The programs are not really special and well-written (as is mostly the case when assignments with short deadlines are concerned), but I polished them a bit, sprinkled some comments over them, and added a big portion of love.

Something like that, anyway.

Since it is not explicitly mentioned anywhere, you need the OpenGL and GLUT libraries in order to compile these programs. It might be necessary to change the library paths in the Makefile if you are not using FreeBSD, which is, judging from the server's log files, unfortunately most probable.

Speaking of operating systems, a fun fact from the log files: Most of my visitors use Linux or Sun Solaris. Either that or somebody really has some fun faking the user agents.

The last update of my local ports collection was most annoying and unnerving. Here are some notes to dodge 3 of the bullets.

Xorg 7.4: Either disable HAL at compile time or add the following to your xorg.conf (assuming your keyboard is configured properly etc.):

Option	"AutoAddDevices"	"OFF"

Else, you would have to configure your keyboard settings (such as layout, rules etc.) in some obscure HAL configuration file that is hard to find. And to be frank, I was unwilling to create some XML files in a directory pretty well hidden on my hard disk just to get my X server to accept input from German keyboards. Seriously, what is wrong with the InputDevice section in Xorg.conf?

libxine: Don't compile it with pulseaudio support if you don't need it. I did compile it with that option and my reward was that programs such as Xine or Amarok would hang. Using the last of their strength, they would utter cryptic messages on the command-line:

caps.c: Dropping root privileges.

Since I did not need pulseaudio, I recompiled libxine, Xine, and Amarok and successfully resurrected them.

CUPS: Be sure to install print/gutenprint from the ports collection. Your applications and printers will thank you for it. And as a boon, you will not get any Unsupported format 'application/postscript' messages because all necessary dependencies will be available.

That's it. FreeBSD FTW!

SAP GUI for Java is SAP's GUI solution for customers that do not use Microsoft Windows or that do not want to use SAP GUI for Windows for some reason. Officially, it is only supported on the following platforms (I have excluded the various flavours of Windows and several other systems. For a full list, see the official SAP document):

• Mac OS X 10.4, 10.5
• SuSE 10.1, SuSE Linux Enterprise Desktop 10
• RedHat Enterprise Linux 4, 5
• Fedora 7, 8, 9
• Open SuSE 10.2, 10.3

What a shame: FreeBSD is not mentioned. The following steps will show you how to install and use SAP GUI for Java under FreeBSD. Why would you want to do that, anyway? One simple, convincing, and perfectly logical reason: Because we can.

The usual disclaimer: Until Tartarus freezes over, don't expect any support from SAP for that.

That being said, the program actually works. I have tested some transactions (see the screenshots later) and encountered no errors. YMMV.

Requirements: You need a working FreeBSD system (I did this with FreeBSD 7.1), the usual X11 ports and a SUN JRE from /usr/ports/java/linux-sun-jre16. I am also assuming that the Linux ABI support is available and works. If you need help with these steps, the appropriate handbook section might help. Grab SAP GUI for Java (choose the Linux version, for example PlatinGUI-Linux-710r7.jar).

Installation: cd to the directory where the installer is located. Use the JRE to start the installation process by executing the following command in a terminal (change the filename if necessary):

/usr/local/linux-sun-jre1.6.0/bin/java -jar PlatinGUI-Linux-710r7.jar 

Choose any installation directory and proceed with the install process. When it has finished, check your selected directory for the folder SAPClients.

After the installation: Open the file SAPClients/SAPGUI7.10rev7/bin/guilogon in a text editor of your choice. Change all references of /usr/bin/test to /bin/test. Finally, set the PLATIN_JAVA variable to your JRE. For example, with tcsh you would to the following:

setenv PLATIN_JAVA /usr/local/linux-sun-jre1.6.0/bin/java

That's it. You can now run SAP GUI for Java and work with your SAP system. If you don't have one, you might want to download a MiniSAP system for Linux or Windows. Trying to install this under FreeBSD is another story...

Finally, some nice screenshots with FreeBSD 7.1, XFCE, and SAP GUI for Java 7.10rev7:

• Fun with transaction SBWP.
• The "About" dialog. Note how the OS is declared to be Linux. Nice, is it not?
• XFCE's transparency effects also work.