Kwakkelflap: tools for the IT pro

Monday, September 24, 2007

Weird crash problem

The new Watchdog – O – Matic version has been released for a while now. I noticed I had a strange crash problem in the new version when closing the program. It only happened on Vista 64 bit. No problems on XP 32 and 64 bit, and no problems on Vista 32 bit.

So I fired up ye olde debugger to locate the problem. The crash seemed very erratic. It crashed at a certain point for no obvious reason, and when I disabled that code, it crashed somewhere else. The Microsoft debugger couldn't help me find the problem. Then I stumbled on an innocent looking line of code at the beginning of the program:

m_pszRegistryKey = "SOFTWARE\\Kwakkelflap\\Watchdog";


This is a string that's part of the CWinApp class that you have to initialize in your application if you want to read something from the registry. It seems that in Vista x64 there is a problem freeing the memory allocated by CWinApp when you close the program causing the crash. So I simply disabled this and everything works like a charm.

Things like this prove once more that a program like Watchdog – O – Matic is very useful for everyone. I bet there are a lot of crashes and unexpected system behavior out there caused by the shift to Vista (and 64 bit operating systems).

Labels: ,

Thursday, August 30, 2007

Automatic currency conversion, part 2

I wrote about the automatic currency conversion system I wrote for the website some time ago. The system works, but there are some issues with it. The biggest problem for me is that the converted price is not always the price at Plimus. Obviously due to a slightly different exchange rate. So I could only display an estimate of the converted price and potential customers could be confused by the difference.

Then Plimus announced that users could use calls to their conversion script. A simple URL with your product ID and the visitor's IP address and you get the converted currency back. I did some tests with their system, and after some PHP tricks it seems to be working. Too bad they do a straight conversion and don't use their own rounding system. But these are both new features, so I expect they will implement this later on.

The system is used on a few web pages for evaluation. It's looking good so far. I'll probably remove the old system this weekend.

Labels: ,

Thursday, August 09, 2007

x64 Conversion

I'm still working on 64bit versions of Watchdog - O - Matic. Right now, I have a beta version that's working on my Vista 64bit and XP 64bit. But there are still some problems on other test machines that need to be corrected.

All in all, creating a 64bit version isn't that hard, except if you have to do some low level stuff. One of the things I had problems with was the system to detect the command line parameters of a running program. You see, when the watchdog checks a running program, it need to know the parameters. Otherwise the program will not restart with the same parameters if it crashed. Windows has a function GetCommandLine() which returns these parameters of the current process. So in order to know the parameters of another process, I need to write in the target process memory, create a remote thread that executes the GetCommandLine() function, wait for the target process to execute the remote thread and read the target process memory to handle the result. You can imagine that creating a 64bit function, and running it in a 32bit application is lots of fun.

One of the biggest challenges however is creating a 64bit disassembler so we can mail disassembly info of the crash. This is a huge task without much gain, so I think that the first 64bit versions won't have this option on board. The primary concern is creating a 64bit version so people with a 64bit operating system can actually use the watchdog.

If anyone is willing to test the beta version, drop me a line.

Labels: ,

Friday, July 20, 2007

x64 Versions and setup

I'm porting our Watchdog application to VC++ 2005. It's a lot of work, and the end result should be no difference for the user. But it's a step I'd have to take eventually.

One advantage of this port is that I'll be able to create 64bit versions of my applications. Some people think it's to early to worry about 64bit, but I don't believe it is. Every new PC sold nowadays is capable of 64bit. And I see a rise in people using a 64bit operating system. Also, it doesn't hurt to be prepared. It's something every misv will have to do eventually, so why not do this early on.

One thing I don't want is a separate download for 32 and 64 bit versions. The installer should check the operating system and install the 32bit or 64bit version. Maybe create an option to install the 32bit version on a 64bit system for compatibility. So I checked Inno setup and apparently they have everything I need (again). Simply set that x86 and x64 are allowed and your setup will automatically detect a 32 or 64bit install. Then, separate the 32bit and 64bit files and add a check with the IsWin64 function to install the correct file. That's all. The setup itself stays 32bit, but that shouldn't be a problem.

It will take some time to create the 64bit versions, and I'll need to test the new system on 32bit and 64bit operating systems. But you can expect 64bit versions of the Kwakkelflap programs in the near future.

Labels: , ,

Tuesday, July 10, 2007

Source Control

As a developer, you need a source control system. Even if you're the only developer.

  • It's great if you have to solve bugs when working on a new version.
  • You can always check the history of each source file to see what happened.
  • Merging different source files is easy.

I used SourceSafe cause it came with the development environment, but never liked it. I don't think it even qualifies as a real Source Control program. So I switched to Perforce a while ago. I love their system. Easy to install, and the GUI is very intuitive. And the best part is: it's free for 2 developers (and 5 client workspaces).

So if you're a developer and you don't use a source control (or even if you do), I advise you to check Perforce. And no, they don't pay me anything to say this. I'm just a very happy user.

Labels: ,

Monday, April 02, 2007

Vista and Inno setup

I'm still adjusting the software to Windows Vista. I think that the clock is ticking as more and more users will be switching to the new operating system. I've made huge improvements with the previous release, but I still need a few tweaks in the setup.

The biggest problem is that my applications need administrator rights for certain functions. One can't expect to be able to debug an application without those rights. This can all be solved without too much hassle, but I want to keep it easy enough for all users.

The previous setups would always disable the User Account Control. While this does solve the problem, it is not the best solution. It would be better to keep the UAC turned on, and still run my programs with administrator rights. So I decided to include a 'manifest file' with my program. This will make sure the application is run with administrator rights. I still want to be able to disable the UAC in the setup though, but it should be something that the user chooses to do instead of disabling it automatically.

So I played with the Inno setup code, and found out how easy it was to create my own function which determines if you want to adjust a registry key or not. I'm always surprised by the power of Inno setup. You can create anything you want using the scripting. Yes, it might require some programming. But you need those programming skills when creating your application in the first place right?

Labels: ,

Thursday, March 08, 2007

Fping speedup

One of the users of Fping informed me of a strange problem. He is using Fping to ping a certain address very fast (once every 1 millisecond with a 1 millisecond timeout). It works as it should. But then he runs a program called 'XNote Stopwatch' and Fping speeds up.

"I stumbled across a strange behavior related to timing. Using the options shown above, I get less than 100 pings per sec. But if I have a program called "XNote Stopwatch" running at the same time as fping, then the ping rate from fping roughly triples. As soon as I shutdown the Stopwatch program, fping returns to the slower rate.
[...]
I get the "stopwatch effect" both with and without -i. I have repeated it on 2 different machines, both WinXP SP2. As soon as I launch the stopwatch program, fping speeds up. As soon as I exit the stopwatch program, fping slows back down. The stopwatch doesn't need to be running."


I'm dumbfounded by this. I am unable to reproduce this on my development machine (also WinXP SP2). But I see the same thing when pinging on my old Windows 2000 system.

I checked the Fping code and it does 2 things related to time:
a) Sleep x milliseconds between pings
b) Query the high performance counter when sending an echo request, and again when receiving the reply to calculate the round trip time.

I'm not sure how the stopwatch program can influence Fping. My guess is they are doing some tricks to get a high precision timing. But this can only influence the high performance counter, if even that. This would result in strange round trip times, not in speeding up. It's hard to believe that they can influence the sleep of another application. I contacted dnSoft (the creators of the stopwatch program) to see how I can solve this.

Labels: ,

Tuesday, March 06, 2007

Automatic currency conversion

A few days ago, Plimus contacted me to let me know they solved the fixed currency problem. I was glad that I could finally put a price in US$ next to Euros on my website. So Sunday afternoon, I started to make some changes.

But then I realized something. How much do I charge my US customers? I could use the current exchange rate and set it at a round number close to it which seemed the honest thing to do. But it would result in rather odd amounts (e.g. $32.00). Another option was to change that amount to the next nice looking number (being $30.00 or $35.00), but that didn't seem fair. So I started thinking. Would it be possible to put a US$ amount that reflects the current exchange rate on my website?

As with all questions in life, Google is THE way to find the answer. I found yourcurrencyconverter which seemed to offer everything I wanted. They check the visitor IP and scan your page for currencies. Then they adjust the currency text to fit the visitor’s currency. I signed up and created a test page with the system. Everything seemed to work fine, and I was glad to have a solution for my problem. Of course, they do show their ad on your page, but for US $49.95 each year, the ad is removed.

But I'm a programmer. So I wondered how hard it would be to create my own system. Not that the US $49.95 would be a problem, but I'm a control freak and I'd feel more comfortable if I have my own system. Also, what happens if their site is down? So I made a deal: if I can make something like this in 1 day, then I'll create it and use my own system. Otherwise, I'll use theirs.

Again, Google in al its greatness found me the stuff I needed to implement it myself. I don't know PHP that well, but it seemed easy enough to figure things out. And after 6 hours, I had my own system up and running. Not all currencies are working right now, but every currency I have dealt with before is (US$, CA$, AUS$, Yen, Euro, GBP, Scandinavian Kronor, ...). So that will be sufficient for now. It's still on my test page at the moment, but I will put it on all my pages in a few days if all works well.

People using Euro will see:



While people from Australia will see:



I guess developers are the worst people to try to sell your software to. If they can make it themselves with a little effort, they will. I hope this solves all my currency issues I’ve had the past few weeks.

Labels:

Wednesday, February 28, 2007

Currency issues

I previously talked about my switch from selling in US$ to Euros. I also asked some people on 'Joel on Software' what they think about the currencies. I was rather startled by the response. It seems that especially US residents want the price in their currency displayed directly on the website. I'm so used to working in other currencies that I personally don't care what currency is displayed, as long as I can switch to my own when ordering.

So I thought it would be a good idea to put a US$ amount on my website. Of course, it would be a little hard to display a changing amount. So the best thing to do was to set the US$ price fixed and use that amount. I'm not that fond of using a fixed US$ amount. Exchange rates can really mess things up. But it's always nice to get extra sales, so I finally decided to do it.

Plimus changed my idea however. Apparently, when you use a different base currency, you can set all currencies to a fixed amount, except US$. US$ just isn't available for setting a fixed currency. Plimus figures you use US$ as a base currency anyway, so it's always fixed right? I contacted Plimus tech support and they said they will implement this 'feature' (I'd call it a bug). I'm curious how long it will take so that I can finally put a US$ amount on my website.

Labels: ,

Tuesday, January 23, 2007

January sales analysis

I wanted to make this analysis for 2 reasons: the switch from RegNow to Plimus and the switch from US$ to euro. How did they affect my sales? I know it's a bit early and I'm not taking the full month into account. In fact, it's only been 2 weeks. But it might be enough to check how things are going.

I don't think the number of sales have been influenced by the change. The amount of orders is equal to the best months of 2006. So switching credit card processors seems to have no influence. The profit has increased. Plimus rates are better and the euro is strong compared to the dollar, so I'm receiving more from each sale.

Product price seems to have little influence on the number of orders. I noticed a growth when I increased the price a few months ago (but there where other factors), and I'm not noticing anything now.

There is a difference in Geography. When I check my orders from each country, the United States was way on top the previous months. Now, other countries are getting closer to the United States. And not only European countries. I’ve seen an increase in sales from Canada, Australia and Japan. Most orders where in euros, while Australian and United States Dollars are tied in second spot. Are US users scared to pay when they see a euro sign or is the price too steep? This might be a fluke, after all we only use this months data compared to the last months of 2006. Something to keep an eye on.

Most people still use regular credit card orders, but there has been an increase in PayPal orders (with Plimus, not by using the link on the website). Why do people select PayPal with Plimus instead of using the PayPal function on my website? The answer is easy: I only have a PayPal link on my ‘Buy’ page. And almost no one is using that page to buy the software. I had one order from someone using the buy page, and it was a site license (which is only available on the buy page). All others order are from within the application, the index page or the product details page. So I need to ask myself: do I need to have the site license on the product pages, and do I need to remove the PayPal option from the buy page? I’ve included the site license on the discount page for now, and I will probably add a clear link to the product page.

That’s about all I can tell for the moment. I’ll create another analysis a few months down the road.

Labels: ,

Thursday, January 11, 2007

First problems with Plimus?

I've been using Plimus for 3 days now. Orders are coming in, and everything seems fine. But yesterday, I received a mail from a customer who told me that Plimus tried to contact him by phone because his order was flagged as fraudulent:
"While reviewing your order for Service - O - Matic we noticed that the phone number you entered is either incorrect/incomplete or we were unable to reach you at that number, please send us a phone number where we can reach you at so that we can process your order."

At first, I didn't know what to think about it. It never happened to me using RegNow. Yes, I had fraudulent orders, but they never contacted the customer by phone for all I know. In response, I send the customer an email with download instructions right away. I always try to give a customer the benefit of the doubt. If the order wasn't fraudulent, then the customer had to wait for the full version. If the order was fraudulent, then that person didn't want to pay for it anyway, and might resort to other means of getting the software for free.

The biggest problem for me is the phone call itself. I don't know about you, but personally I hate phone calls. I think it's highly intrusive. Not only that, but Plimus is in a different time zone. They made the call more than 6 hours after the order, and it was 22 o'clock local time! I sell to business most of the time, and I know that I won't be answering business calls at 22 in the evening. No wonder the customer didn't answer the phone.

Anyway, I contacted Plimus about this, and they advised me to use a different order processing company if I didn't want them to phone my customers. They have to make a ton of money if they don't want a vendor that earned $1500+ in the first 3 days (hey, I told you January would be a good month).

I'm not sure how frequent these calls are. I'll be checking this in the future.

Labels: ,

Sunday, January 07, 2007

Plimus switch

I just made the switch from RegNow to Plimus. It was more work than anticipated. Changing the urls in the programs was no big deal. But you can’t imagine how much buy links I have on the website. And, I had to update all program information.

The affiliate system has also been changed. New affiliates will be using Plimus. I still support RegNow for older affiliates, so there is no need to change anything for them. The only problem is that I’ll have to update my prices now and then at RegNow. I’m selling in Euros on the website, and RegNow only supports US$. I’ll probably check them once a month to keep them inline with my Plimus account.

Now, all I have to do is wait for the first Plimus order to roll in.

Labels: ,

Wednesday, January 03, 2007

Plimus test

Some time ago, I talked about my payment processor RegNow, and how they work. I also talked about the Dollar-Euro conversion rate. All of this made me believe it is time for me to switch. I heard a lot of good stuff about Plimus, which is not part of the Digital River network. All payment processors bought by Digital River seem to use the same way of earning money: an x% + y$ plan which I’m not that fond of. Plimus has no setup fee, so I can basically try them out for free. And their % on sales seems alluring. They even had a conversion offer, which means that they would create all my products using the information from RegNow and my website.

I wasn’t that impressed with Plimus at first to tell you the truth. The interface seemed clunky and it was hard to find everything I needed. So I didn’t check them out after signing up. Today, I went back and I was impressed with the way they converted all my products. This is a great incentive to switch, because a lot of work was already done for me. So I spend some time fine-tuning everything. I still hate the interface, but I’m getting used to it. And then I discovered the real reason I want to switch: I can sell in any currency I want. Want to sell in Bahamas Dollars, or Iceland Kronur? No problem. So I can sell all my products in Euros if I want to. There are still a few minor issues like product bundles. But there are workarounds.

So I will probably switch to Plimus in a few days. I’m still thinking of using affiliates for RegNow. I’m not sure at this point. I updated Sniff – O – Matic and changed all the buy links to Plimus instead of RegNow. I’ll use it as a test before I make the big conversion. I think I’ll need a day changing all the buy links in the software and on the website, so I want to know if it’s worth getting into.

Labels: ,