Monday, August 29, 2011

Stores selling cheap stuff from China

There are many online stores which sell a wide variety of cheap stuff from China, usually with free shipping. The prices can be impressively low, but the quality is sometimes questionable.

DealExtreme seems to be the most popular one. So far, I've ordered several items from there, and overall I've had a good experience. I'm using the 10W 500-Lumen Multi-Color RGB LED Emitter Metal Plate (140 degree) in my RGB lamp, and I'm happy with it. Their 5mm white LEDs are also good, with a nice colour and good brightness. I also got a nice 55mm lens cap.

So far, I've only had one problem with DealExtreme, and that was resolved in a good way. I ordered what was at the time advertised as a Massa circular polarizer for my camera. The packaging and item I received made no mention of Massa, and the item looked different. When I contacted DealExtreme, I got some store credit. The polarizer does provide decent photos as long as I don't zoom much, and I really like some photos I took using it. I also see that DealExtreme updated the item description and photos, showing what I got. As a result of all of this, I'm satisfied.

My favourite thing about DealExtreme is the reviews and forum posts. They seem genuine, and they provide useful information about the products. Yes, DealExtreme does sell some bad products, but the reviews and other information make it possible to avoid most of these.

The only real complaint I have is that some simple actions (such as redeeming store credit or DX points) require customer service interactions. These things would be easier and faster if automated. However, customer service always responded promptly, so this is not a major issue.

The main thing that motivated me to write this post is my first purchase from DinoDirect and what I saw when I spent more time on that site. It's a big contrast; DealExtreme is much better. For example, check out what other people have to say about DinoDirect, and look at the quality of item reviews on DinoDirect.

Monday, August 15, 2011

I'm still using Adobe Reader

Despite the bloat and all the people who hate it, I'm still using Adobe Reader to view PDFs in Windows. Recently, it was slow on one huge PDF on my laptop, so I decided to try out some alternatives.

Sumatra PDF was pretty good and a bit faster, but zooming wasn't as user-friendly. I didn't like Foxit Reader's user interface. It seemed like an old badly designed Linux application. PDF-XChange Viewer was pretty good, but it also had an inferior zooming user interface. The biggest problem was that all three had slow search in large PDFs, without acceleration via saved indexes like Adobe's Fast Find.

It would have been nice to switch to something leaner, but it's not really a problem. I found that disabling 2D graphics acceleration in Adobe Reader resolves the performance issues on my laptop.

Sunday, August 14, 2011

Bad capacitors and ESR testing

I have an old Soltek SL-65KVB motherboard. It was taken out of service due to AGP graphics instability which was probably due to bad capacitors. This diagnosis seemed pretty obvious because capacitors right by the AGP slot were bulging, but I didn't bother fixing the motherboard because it was a good time for an upgrade.

Now I would like to repair the motherboard, mainly because the combination of a Pentium 3, 640MB of RAM and an ISA slot could provide a nice way to use old hardware. By now, even more capacitors are obviously bad. However, only the GSC 1000µF and 1500µF 6.3V capacitors with gold/brown lettering have obvious problems and more numerous smaller GSC capacitors with silver/white lettering seem fine.

I didn't feel like unnecessarily replacing the smaller capacitors, so I quickly built a very simple capacitor ESR tester. The basic idea is the same as various other ESR measuring devices documented online: a stepdown transformer outputs low voltage and low impedance pulses which are used to measure capacitor ESR. I built the stepdown transformer from an inductor with a short secondary wrapped around it, and I used a 555 chip to supply low duty cycle pulses at high frequency. The 555 can supply enough current that it's possible to directly drive the transformer with a resistor in series with the primary.

My first attempt with a secondary of just a few turns worked pretty well when capacitors were plugged into the breadboard. However, test leads had enough impedance to make the circuit useless. Reducing the oscillation frequency to around 100 kHz and adding more turns to the secondary improved performance, making the bad capacitors very obvious. Test leads were still a problem however. Adding a 1Ω resistor in series with the secondary improved the situation significantly, so I proceeded to test the small capacitors on the motherboard via test leads.

It seems the small capacitors are all ok. However, among the large capacitors, even most that weren't bulging are bad. Only two of the ten 1000µF capacitors have a low ESR. Of course, considering the other failures, these shouldn't be used for anything either.

Wednesday, August 03, 2011

g++ dyamic linking fail

I have a DLL which works when built, but stops working later. Simply rebuilding it creates another copy which again works and stops working later. LoadLibrary returns error 998, which mean "invalid access to memory location". In other words, a crash occurs in the DLL being loaded. The crash occurs when calling _initterm from code at the DLL entry point. At __imp__initterm there should be a pointer to _initterm in msvcrt.dll, but the location instead still contains the value that's in the file on disk. As a result, if msvcrt.dll is located at a different location, the program jumps to the wrong location. I guess this happens because msvcrt.dll is imported two times. The first import just uses _write, which is properly dynamically linked. The second import lists all the other functions that are used, and dynamic linking wasn't done for any of those. The _write from the first import is just used to print "pure virtual method called\n".

I suspect that g++ is to blame, but I'm still not sure. The problem is now happening with g++ 4.5.3 from the 32-bit MinGW-w64 Cygwin package, but the same symptoms occurred when using the old Cygwin compiler that is based on GCC 3.

Update: The problem seems to be related to statically linking libstdc++. The duplicate msvcrt.dll exists when using -static or -static-libstdc++ (new in GCC 4.5).

Update 2: Packing the DLL with UPX 3.07 seems to fix the problem. When a packer compresses the IAT, it needs to handle dynamic linking. Apparently UPX is able to properly handle the defective IAT.