## Video: The state of Floating-Point, circa 1995

Recently, I digitized several VHS tapes from the  “Bay Area Computer History Perspectives” series of lectures. These lectures were sponsored by Sun Microsystems Inc (alas, now only a ghost image of its former self since the Oracle merger) in the mid-90’s.

They feature big names involved in the history of these topics (ie: original designers, scholars of the time, experts). There were around 25 of these lectures, but I only have 5 of them 🙂 Nevertheless, I shall make them accessible to you, provided Google doesn’t think I am using too much bandwidth.

The first lecture I make available is entitled “Floating-Point— Past Present and Future” (5/9/1995). The lecturers discuss the history of floating point, a lot of technical anecdotes, as well as analysis of the past, present (1995) and future (now I guess) of floating point.

The lecturers are:

Don’t miss Pr. Kahan’s appeal for graduate students in the field of floating-point and numerical analysis near the end 🙂

Click on the screenshot to reach the video hosted on PicasaWeb:

## Release of the extract_lines Python module

Yesterday I wrote-up a page about extract_lines, a Python module I developed recently to automate some text extraction tasks.

Many engineers have to analyze tabular or line-oriented human-readable reports and source code. For instance, suppose we want to extract constant coefficients from a C source file (snippet taken from Bessel functions of the first kind of order 0 from uClibc):

```static const double u00 = -7.38042951086872317523e-02, /* 0xBFB2E4D6, 0x99CBD01F */ u01 = 1.76666452509181115538e-01, /* 0x3FC69D01, 0x9DE9E3FC */ u02 = -1.38185671945596898896e-02, /* 0xBF8C4CE8, 0xB16CFA97 */ u03 = 3.47453432093683650238e-04, /* 0x3F36C54D, 0x20B29B6B */ u04 = -3.81407053724364161125e-06, /* 0xBECFFEA7, 0x73D25CAD */ u05 = 1.95590137035022920206e-08, /* 0x3E550057, 0x3B4EABD4 */ u06 = -3.98205194132103398453e-11, /* 0xBDC5E43D, 0x693FB3C8 */ v01 = 1.27304834834123699328e-02, /* 0x3F8A1270, 0x91C9C71A */ v02 = 7.60068627350353253702e-05, /* 0x3F13ECBB, 0xF578C6C1 */ v03 = 2.59150851840457805467e-07, /* 0x3E91642D, 0x7FF202FD */ v04 = 4.41110311332675467403e-10; /* 0x3DFE5018, 0x3BD6D9EF */```

A common case would be to transform that data so it can be more easily used within a spreadsheet or another program, in a form such as this:

```u00,-7.38042951086872317523e-02 u01,1.76666452509181115538e-01 u02,-1.38185671945596898896e-02 u03,3.47453432093683650238e-04 u04,-3.81407053724364161125e-06 u05,1.95590137035022920206e-08 u06,-3.98205194132103398453e-11 v01,1.27304834834123699328e-02 v02,7.60068627350353253702e-05 v03,2.59150851840457805467e-07 v04,4.41110311332675467403e-10```

Whenever data must be extracted from that kind of document, it usually involves a big mess of cut’n’paste sprinkled with search and replace. For the most part, it is a job of manual editing, especially if it is a one-time affair. However, what happens when we must automate the task ? Tools such as sed, grep and awk within UNIX shell pipelines can do the job, but they are somewhat inflexible and pretty hard to use. Furthermore, they don’t allow the programmer to easily process the data within the same program that does the extraction.

The extract_lines module was written to facilitate the automation of these tasks in Python with Regular Expressions. Several examples are provided on the project page. Take a look 🙂

## DL4195A v1.2 released

A new version (1.2) of the DL4195A program is now available.

• Fixed a bug where the program would crash if no serial ports at all were installed on the machine
• Added a textual description of the serial ports using the Windows registry
• Fixed a build issue on Windows Vista x64

You can download it here (Win32 binary + Python sources) or visit the project page.

## Integrated 18-26V @ 4A CAN Bus Drive for Seabotix Brushed Thrusters

### Disclaimer

The intellectual property for this project does not belong to ETS since it was designed while I was doing an internship away from ETS, using my own CAD software licenses on my own computer. I have given away all rights to this design to the public domain, which includes unlimited usage by SONIA and others. The firmware is an intellectual property of Jean-François Dionne and ETS, and as such, is not available on this page (although it is very simple to rewrite it). Neither Tennessee Carmel-Veilleux, SONIA or ETS are responsible for any material or moral damage, lost income or fitness of purpose related to this design. Liability in following these instructions lies with the executer.

### Introduction

This is a project I have designed while involved in the SONIA student club at Ecole de Technologie Supérieure (ETS). Since 2005, SONIA has been using the great BTD150 ROV thrusters from SeaBotix for their vehicle. During the 2006-2007 competition year, we used a proprietary LIN-protocol drive to replace the BTD150’s default I2C version.

In 2007, we switched our drives to this model, which was designed to match the vehicle’s main peripheral CAN bus so that the LIN support could be dropped. We also wanted a 100% non-proprietary circuit so that every member of the team could look at the plans without signing an NDA. This is why the CAN version was designed.

### Requirements

The requirements for this drive were simple:

• The mechanical form factor must fit within the BTD150’s housing
• The PCB must be at most 4 layers
• A CAN bus port supporting at least 125k baud must be present
• Input voltages from 15 to 26V must be supported
• Maximum thruster power (75W) should be supported continuously at 24V
• Thruster speed must be variable between 0 and 100% with at least 64 discrete level but not necessarily closed-loop controlled
• Current-limiting and stall-protection circuitry must be provided to enable these functions in the firmware
• Board temperature and current must be monitored
• Parts should be easy to source for at least 3 years at many different distributors

### Design (files at the end)

#### Microcontroller and CAN communication

With these requirements in mind, I designed a circuit around the PIC16F690 motor-control microcontroller (MCU). This MCU is easy to program with common tools and is very robust. It also contains an enhanced PWM module that can do hardware-assisted current limiting, as well as configurable signaling different types of H-bridges used in brushed motor control. I used 3 square pads with 0.1″ spacing in an “L” configuration for the ICSP (In-circuit serial programming) port, with the ground on a fourth flying lead. A pogo-pin adapter went between the drive PCB and the PIC programmer.

Although the PIC16F690 has SPI, I2C, USART/LIN ports, it does not possess a CAN controller. For this task, we used an external MCP2515 SPI-bus CAN controller. The CAN transceiver PHY is the low-cost MCP2551. This chipset proved simple to integrate and supported the minimal requirements we had for CAN operation. The 8MHz crystal oscillator XT1 provides a low-jitter, high accuracy clock for the CAN controller. The MCU is clocked from an internal 8 MHz RC oscillator.

#### H-Bridge and monitoring

The drive uses a classic symetrical MOSFET H-Bridge with low-side current monitoring. It uses an original high-side drive that is well adapted to infrequently changing motor direction and very small to implement on the PCB. High-side gate turn-off is deliberately faster than turn-on, to prevent gate breakdown because of too high a voltage during the transition from conduction to turn-off.  A conscious choice was made to omit low-side freewheeling diode because of space constraints. Therefore, the drive uses the internal body diodes of the low-side N-channel MOSFETs for that purpose.

The gate drive logic is meant to have static high-side “direction selection” mode and very fast, low-impedance gate-drive on the low side, to reduce switching losses. The gate-driving PWM signals are generated by the PIC16F690’s enhanced PWM module and feature hardware current-limiting cutoff from an internal comparator tapped on the current measurement. The low-side dual gate driver is the ubiquitous TC4427. The PWM frequency is programmable such that the drive can receive either a “default” configuration or be tuned to the particular load with which it is used.

To monitor the current, a single-ended measure is made on a low value shunt. The OP-amp, a TLV271, was chosen to also act as a first order filter by way of its GBWP (Gain-Bandwidth Product). Since the voltage gain is very high (approx 40 dB), the low bandwidth of the amp restricts response time, which forms a filter around 30kHz, depending on fabrication processes. Extra filtering can be added to obtain an average current rather than a more classic exponential sawtooth by way of an RC filter formed by R4 and optional C4.

The temperature and supply voltage signals are converted by the MCU’s internal ADC. A low-cost MCP9701 temperature transducer is used to get a linear transfer function between degrees Celcius and volts.

#### Power supplies

The power supplies are provided by inefficient but robust 78Lxx regulators in SOT89 packages. The NJR units selected have been shown over time to exhibit extra robustness when operated at high temperatures for long periods of time. As much decoupling and bulk filtering was added as space would allow. The only compromise was made in the input filter. An MCP120T reset monitor can be patched-on if device lock-up occurs because of large dips on the input supply (ie: sagging caused by large transient loads). Since the built-in Power-On Reset of the MCU is used, this condition can occur when the power supply at the end of the cable is marginal. Experience has shown that this is not necessary except in pathological cases of high-loss source-to-thruster power path.

#### Layout and assembly

Much care was devoted to the routing of the drive’s PCB to insure reliable operation in harsh conditions. After all, the drive is fully enclosed and a brushed DC motor is spinning very fast with a high load ! A heat spreader can be installed on top of the MOSFETs and held in place with the center retaining screw. It may seem useless, but it more than doubles the available surface for heat dissipation in the ambient environment.

The PCB is a 4-layer FR4 PCB with standard 1/16″ (62.5mil) thickness. Minimum trace width is 10 mils and spacing is 10 mils. Contour routing is important and the provided board outline layer is the external contour, not the tool path. All footprints were drawn for ease of hand soldering (roughly equivalent in most cases to “M”-series IPC-7351 standard land patterns). As mentionned above, a programming tether must be constructed to program the PIC. It is very easy to do with 3 pogo pins on a small piece of 0.1″-spacing prototyping board and an easy-hook ground lead. Full Gerber and Excellon data is provided in the fabrication archive.

The BOM is available on the last page of the PDF file containing schematics and board prints. This BOM can be used both for assembly and for part ordering. Most parts are from Digikey.

### Field deployment

The drive firmware was programmed very quickly by Jean-François Dionne of our team, based on previous work by Jean-Pierre Marcotte. I participated in writing the driver for our main software stack on the embedded PC. This drive was assembled in more than 20 copies. No catastropic malfunction (apart from a single water leak) has ever occured over 3 years of active use as the sole drive on two AUVs and one ASV. Overheating has not occured because the current-limit and stall protection scheme prevents heat build-up.

We have had several occasions of stalled thrusters being driven for hours before someone realized the stall, without a failure. We did in fact burn through a BTD150 winding before the current limiting was in place in the firmware. This drive design has stood the test of time and is the workhorse for SONIA in terms of thruster drives.

### Conclusion

I hope this design can be helpful either as is, or as an example of a working design for a fully integrated BTD150 drive. I encourage anyone to use this circuit at large. However, do consult the disclaimer.

If you require the original editable EAGLE-format schematics and board files, I can provide them depending on the application.

## Resources For Learning SWT/JFace

The Standard Widget Toolkit (SWT) from the Eclipse project is a great native GUI toolkit for Java that is gaining in popularity constantly because of the Eclipse Platform‘s success.

The learning curve for this toolkit can be easier if you are careful about the sources of information you use to get started. That’s because a lot of the documents currently available online and in books are quite dated. However, since the toolkit is mostly backwards compatible, you will be safe if you don’t thread the RCP (Rich Client Platform) grounds at first and get acquainted with “basic” SWT and JFace first.

Below are some excellent resources I have regrouped that have helped me get a great headstart on the SWT/JFace API.

### Online resources

IBM DeveloperWorks has a ton of great articles on getting started. Eclipse Corner also has some very good articles. I have collected links to several articles that were directly helpful to me:

• A Gentle Introduction to SWT and JFace” is a 4-part tutorial series covering all the basics of getting an application up-and-running with SWT/JFace. It covers all the important concepts in a chronological order and contains many snippets for common constructs. Beginners start here 🙂

• Using the Eclipse GUI outside the Eclipse Workbench” is a 3-part tutorial series that also covers all the basic aspects of SWT/JFace, from shells to widgets to JFace Viewers and Actions. It builds progressively on the example of a file browser similar to Window’s Explorer, with directory tree, file table and menus. The example is complete and a lot of implementation subtleties are covered through the three parts.

• Understanding Layouts in SWT” at the Eclipse Corner is the definitive reference about SWT Layouts. It covers this major aspect of SWT programming with a ton of visual examples and independant snippets of code. It can easily be printed or saved as a Webpage with your browser for later perusal since it contains no sidebars or ads. Strongly recommended.

• The SWT Snippets and JFace Snippets pages are essential references for the beginner and the expert alike. The vast majority of features are covered in easily digestibly nuggets of code that can be run without additionnal scafolding to experiment.

• Graphics Context – Quick on the draw” at the Eclipse Corner is an introduction to SWT Graphics, the equivalent of Swing/AWT’s java.awt.Graphics class. Many screenshots document the code snippets provided. This tutorial does not cover the Advanced Graphics subsystem (equivalent to java.awt.Graphics2D).

• Eclipse Forms: Rich UI for the Rich Client” at the Eclipse Corner is a complete tutorial on using the Forms API. This API allows one to create very rich form dialogs and wizards with very little effort. This article is complemented by “Eclipse Forms: New in 3.3” that covers some interesting new features that were introduced in Eclipse 3.3.

• Swing/SWT Integration” at the Eclipse Corner covers the AWT/SWT bridge that appeared in Eclipse 3.2. This bridge allows developers to include Swing and AWT controls within SWT applications in a mostly transparent manner. The article describes the process and pitfalls of applying the bridge and links to the a sample helper class to get you started in using the bridge.

• Java2D Under SWT: Coercing Graphics2D Functionality into SWT” is my blog article about using Java2D within SWT applications. It covers four different methods to include Java2D canvases in your SWT programs with the least amount of pain.

### Books

After discussing it with colleagues and looking-up reviews on Amazon.com, I decided to get a book so that I would have a desktop reference in my favorite format: paper :). My choice was “Java Native Interfaces with SWT/JFace” by Jackwind Li Guojie.

I was very satisfied with this title and it covers all of the essentials for getting started with plenty of snippets and a fully worked integration example. The writing style was clear and concise. Both SWT and JFace where covered, including widgets, layouts, tables, trees as well as JFace Viewers, Text, Forms and Wizards. All in all, a great title for the price. This book is also available as an e-book on Books24x7, which is a good (free) deal if you are a College Student or professional member of ACM or IEEE Computer Society.

Many other books are available, but most “classic” references cover Eclipse 3.0 or Eclipse 3.2. If you want to be cutting edge, nothing beats a little blog search or the official documentation 🙂

### Other Resources

Even though the SWT official documentation is basically just the Javadoc, there is quite a lot of important information in the Platform Plug-in Developer Guide that comes with the Eclipse SDK.

## Java2D under SWT: coercing Graphics2D functionality into SWT

I am currently working on a medium-scale personal project in Electronics Design Automation. I am usually very keen on building scripts and programs to make board-level design tasks faster for me and others. This time around, I am designing a Package Generator program to generate footprints for different CAD packages according to IPC7351A specifications or user-provided rules. The goal over time is to support EAGLE and Altium DXP at the very least.

During the design phase, I decided early on to use the Eclipse’s SWT (Standard Widget Toolkit) instead of Swing for the GUI of my application. The reasons for this will be covered in a later entry about SWT.

My application calls for a significant amount of custom rendering so that a footprint preview control is available. Since footprints are 2D CAD drawings with a lot of detail and geometrical transforms apply, I needed a graphical framework that would make it easy.

Basic screenshot of Java2D control in PackageGen

## Issues with SWT’s graphics package

While browsing tutorials and books for SWT, I realized that SWT’s org.eclipse.swt.graphics package is really immature compared to the rest of the framework. Here is a short list of the shortcomings I have found that affected my application:

• Affine transforms for arbitrary shape drawing are barely discussed and poorly documented.
• Paths in the drawing system (equivalent to the Shape class of Java2D) are awkward to use.
• Transformed (rotated/scaled) fonts are affected by explicit issues in SWT’s font API.
• Fractionnal point sizes are not supported.
• String drawing uses the “point size” as the user-space transformed size.
It was obvious at that point that if I could find an easy way to use Java2D under SWT, it was the way to go. It did take several days of research and trials to evaluate all the possibilities, but I have found my way 🙂

## Solution: methods of using Java2D under SWT

During my trials, I found four different methods of using Java2D under SWT, each with its advantages and shortcomings. I list them here in the order in which I implemented them:

In the end, I implemented J2D4SWT and I am really satisfied.

### Method 1: BufferedImage rendering on SWT graphics context (GC)

This method is probably the simplest idea for integrating Java2D functionnality under SWT. It is well described in “Java 2D imaging for the Standard Widget Toolkit” at IBM DeveloperWorks. The article also contains a sample helper class (Graphics2DRenderer) to start using the method immediately.

The idea behind this method is simple: we use an AWT offscreen BufferedImage for rendering and then transfer the pixels to an SWT GC. The BufferedImage class in the java.awt.image package contains a createGraphics() method that returns a Graphics2D context on which to draw. The buffered image also allows access to its raster and the data is copied pixel-by-pixel to the SWT Image. The Graphics2DRenderer class automates all of this and wraps the AWT BufferedImage and SWT Image under the hood.

Of course, since this method implies pixel blits entirely in Java, it is extremely slow. The concept is good enough to be reused in a much more optimized way by the J2D4SWT library (see below).

• Simplest method to use
• Only a single Java class required (and freely available, sources included)
• No interference with SWT-only rendering
• Completely transparent

Shortcomings:

• Very slow compared to native SWT GC methods

### Method 2: JFreeChart.org’s experimental wrapping of the GC into a Graphics2D object

The JFreeChart project develops a full-featured plotting and charting library in Java with Swing controls. Over the years, there has been experimental work to allow some integration with SWT. Part of these efforts were aimed at adapting the Graphics2D class to the SWT GC. The method they have chosen is to reimplement all the main calls of Graphics2D by adapting them to equivalent org.eclipse.swt.graphics.GC. The idea is very good since it only requires a small amount of highly-targeted adapter classes. However, because of some of the shortcomings specific to SWT’s GC (especially fonts), there remains some porting issues.

JFree’s current implementation is still experimental and can be found in the org.jfree.experimental.swt package on SourceForge. It is mostly undocumented, but really easy to use. The adaptation is remarkably elegant, considering that the implementation uses conversions of Fonts, AffineTransforms and Shapes to their equivalent SWT version (Font, Transform and Path).

As an example, with the SWTGraphics2D class, you could fill a canvas with a black rectangle using Java2D as follows:

```drawCanvas.addPaintListener(new PaintListener() {
@Override
public void paintControl(PaintEvent event) {
// Get size of source control
Point controlSize = ((Control) event.getSource()).getSize();

// create a g2d instance on the GC
SWTGraphics2D g2d = new SWTGraphics2D(event.gc);

// Reinit transform
g2d.getTransform().setToIdentity();

// Fill background in back
g2d.setPaint(Color.BLACK);
g2d.setColor(Color.BLACK);
g2d.fillRect(0, 0, (controlSize.x, controlSize.y));
}
});```

This method is very quick’and’dirty if you need to do some simple Java2D drawing under SWT or prototype a previous custom control on SWT before porting. It still needs some work but since you have the sources, you can fix the bugs rather easily.

• Very fast rendering, even with Graphics2D methods
• Only three Java classes required (and freely available, sources included)
• No interference with SWT-only rendering
• Completely transparent

Shortcomings:

• Very experimental
• Many Graphics2D methods are not implemented (ie: rotate(double theta, double x, double y))
• Some glitches in font rendering (sizing issues) and Shape conversions (misalignments)
• Still buggy and requires changes to Java2D code to adapt to bugs

### Method 3: JPanel rendering under the AWT/SWT bridge with helper classes

The AWT/SWT bridge introduced in SWT 3.0 allows one to integrate AWT/Swing widgets into SWT. Performance is much better than the BufferedImage rendering method and native AWt/Swing events are supported. Using the bridge, you can thus add a simple JPanel on any SWT Composite and perform custom painting in the paintComponent() method. At this point, you are actually using Swing directly and SWT handles the rest. There is an excellent article on Swing/SWT Integration by Gordon Hirsch at the Eclipse Corner. This article covers all the specifics of using the SWT/AWT bridge and also provides an integration example with full Javadoc (used in the code below). The following snippet shows how to add a JPanel to your SWT application:

// Native composite creation as child of myComposite

```EmbeddedSwingComposite drawCanvas =
new EmbeddedSwingComposite(myComposite, SWT.NULL) {
protected JComponent createSwingComponent() {
return new JPanel() {
protected void paintComponent(Graphics g) {
Graphics2D g2d = (Graphics2D)g;
// ...
// Your custom paint operations go here
// ...
}
};
}
};
drawCanvas.populate();```

This would seem like the best way to go. However, if you think about it, you are using a full AWT event thread and native controls just to be able to draw using Java2D. If your application already calls for Swing components integration, this is great. If you rather want to be 100% SWT, then this method is overkill because it adds a high level of difficulty in event handling under SWT. When a Swing component is bridged, getting the events under SWT is a nightmare. Most event handling must be done within the Swing event model, which adds complexity (and Swing-ness) to your project.

• Uses Swing/AWT natively for Java2D (no pixel-blitting/redrawing)
• Allows the use of composed Swing components
• Necessitates only small amounts of code

Shortcomings:

• Event handling within SWT is almost impossible
• Method is overkill when only Java2D is required and not the rest of Swing
• Hard to use and riddled with gotchas if you don’t use an integration example

### Method 4: J2D4SWT rendering package from Holongate.org

After some research, I found the J2D4SWT package by Christophe Avare. Its architecture is meant to allow the use of Java2D seamlesly with SWT. Internally, it uses the offscreen rendering method. To increase performance, it includes some native accelerations under Win32-x86, GTK-x86 and Motif-x86. Since it is an open-source project, the acceleration code can be recompiled on other targets.

The J2D4SWT package not only contains the Java2D encapsulation API, but also some optimization schemes for the repainting of controls. When a native acceleration is not present, the implementation uses an SWT-only version that is slower but fully portable accross all platforms.

An IPaintable interface is provided to ease the implementation of Java2D-aware SWT canvases. The main class that can be used to enable Java2D on SWT with J2D4SWT is J2DCanvas which derives from SWT’s Canvas. It is completely native but uses the accelerated drawing primitives and an associated IPaintable interface to render the contents on repaints.

 Main interfaces diagram from J2D4SWT Available canvases for J2D4SWT

There are several related libraries on the holongate.org website, including SVG support with the Batik library and a Draw2D/GEF integration to use Java2D as the Draw2D renderer.

Overall, the J2D4SWT library is the easiest to use and fastest method out of the 4 that I have tried. It is very well documented (full Javadoc) and elegant in design, encompassing additionnal detail beyond simple Java2D implementation.

• Very easy to use
• Native acceleration on the most popular platforms
• Unified SWT/Java2D canvas class
• Completely transparent
• Highly compatible with Java2D (no glitches)

Shortcomings:

• Acceleration requires a target-specific library

## Conclusion

As you can see, the problem of using Java2D under SWT has been well studied before and there are many ways to make the most of SWT while not leaving Java2D behind. In forthcoming entries, I will discuss solutions to a functional bug in native scrollbars as well as an overview of resources for learning SWT.

## Sources of toolbar icons for your GUI applications

If you’re like me, you have had to deal with finding or drawing tons of toolbar icons over your programming career for all those GUI applications that require them. Sometimes you get lucky and you can cut’n’paste from a screen grab or get them from a previous project.

What happens, however, when you want to distribute an application ? Well, you can buy icon packs from companies that offer royalty-free licenses OR you can try to find open-source programs or icon sets that are freely available.

I’ve been working on an EDA (Electronics Design Automation) utility program in Java for the past while and I have had to search far and wide for good icons to use. While discussing with a colleague, I got some of his links to stashes of icons. I also downloaded the sources to The GIMP (GNU Image Manupulation Program) and looked at their icon set. During my searches, I have come-up with some interesting links to some great icon collections:

• The Crystal Interaction Design Project by Everaldo Coelho. This is a very large collection (1300 icons from 16×16 to 256×256) of stylistically-related icons covering the gamut of application design requirements and targeted at the KDE Platform. I find they can be used in about any GUI project. Mini preview is available here.

• The Silk icon collection by Mark James. This is a collection of 700 icons of 16×16 that also covers all aspects of general applications needs (toolbar actions, file types, table symbols). They have a very neat look and are freely usable under a Creative Commons attributions license. A full preview is available.

• The Nuvola icon set by David Vignoni. This collection features more than 600 icons in many different sizes, most of them “toolbar-size” (16×16 and 22×22) PNGs. They have a very neat look and cover a lot of applications. Here is a preview screenshot for the set. Usage must follow the LGPL.
A lot of these icons are also linked from KDE-look, which is a website containing tons of open-source artwork for KDE. Since KDE applications use a theming system, most of the icon packages contain a variety of very useful toolbar icons encompassing text formatting, media players, clipboard operations, etc. I hope you will find these icons useful in your applications.

## PDFCreator 0.9.6 finally supports Vista (get it!)

I recently realized that PDFCreator now fully supports Windows Vista. PDFCreator is probably the best free PDF-making software for Win32 systems. It not only outputs PDF, but also PNG, TIFF, JPEG, PS and a host of other formats. It acts as a Printer driver under Windows (98, Me, XP and Vista) so it is very easy to use it. What is really interesting is that it does not contain any crud like many other free PDF software and it features a print spooler so that you can combine printing from many programs into a single PDF file. This way, you can build a full document, with annexes, in a single pass.

I’ve been using PDFCreator for more than 4 years now, but I had to let it go for one year on my laptop because it had an integration issue with Vista. Since version 0.9.6, Vista support is there after a 150\$ bounty got filled on the open-source project. I strongly recommend you try it ! After all, how can 20 million users be wrong ? 🙂

## Fixing DNS proxy issues in Vista ICS with Acrylic DNS proxy

### The Problem:

I recently installed Ubuntu Linux on my old PowerMac G4 “QuickSilver” tower. During the installation, I needed to use my internet connection over WiFi to download the installation packages. I tried using Linux’s WiFi support with my Mac’s AirPort card, but to no avail. It could see the access points, but not actually connect to them. So I decided to use a network cable to connect to my Windows Vista laptop to share its WiFi connection. I got the Vista ICS (Internet Connection Sharing) working using some easy-to-find instructions online.

Windows’s ICS still did not work because the DNS server provided by Window’s DHCP server was the local PC’s network address (in my case 192.168.0.1). The Windows DNS proxy, for some reason, did not work and so I could not resolve any site, even though I could ping existing IP addresses. I have read several accounts online (including this one) saying that the DNS proxy in Windows is very fragile and often does not work. The default resolv.conf configuration created by dhclient from Window’s DHCP server is like such:

search mshome.net
nameserver 192.168.0.1

### The Fix:

To get the DNS resolution working without jumping through hoops, I figured I could just use a simple third-party DNS proxy. After maybe 5 minutes of searching, I found the open-source Acrylic DNS Proxy. It is a very simple proxy which runs as a Windows Service and provides local DNS caching. It can be configured in 1 minute: all you need is the IP address of your ISP’s DNS servers (which can be found in your router’s Status Info pages, amongst other places).

After I got Acrylic DNS Proxy running, the default 192.168.0.1 DNS provided by Windows started working. The Linux internet connection shared from the PC was working and I could install Ubuntu and download the necessary updates. As a welcome side effect, DNS resolution for often-accessed pages under Windows was also quicker, thanks to the primary purpose of the DNS proxy 🙂

As a side note, Eclipse is brutally slow on my PowerMac G4 867MHz with Linux ! I think we forget how slow large Java programs are until we try them on machines that are 5 years old 🙂