September 24, 2004
Fix for Windows Update 5 Errors
Ever since Microsoft pushed Version 5 of Windows Update onto my XP SP1 system, I have been unable to access Windows Update - until just now. I found it!! I just accessed Windows Update and successfully downloaded and installed updates to my system.
The particular error message I was getting was 0x80072F78 (appeared when Windows Update tried to find the updates for my system), but I think this solution will fix the problem on systems getting other error messages as well. If your error code starts with "800", I think there's a good chance this solution will help.
Create a file on your desktop called wu5_fix.bat and put the following lines in it. (Leave out the dashes on the top and bottom - I'm just putting them there to separate the batch file contents from the rest of the text.)
------------------------------------
net.exe stop wuauserv
cd /d %windir%
rd /s softwaredistribution
REGSVR32 %windir%\system32\wuapi.dll
REGSVR32 %windir%\system32\wuaueng1.dll
REGSVR32 %windir%\system32\wuaueng.dll
REGSVR32 %windir%\system32\wucltui.dll
REGSVR32 %windir%\system32\wups.dll
net.exe start wuauserv
------------------------------------
[[16-Feb-05: This batch file was edited to include an additional Windows Update DLL (wuaueng1.dll). The problem recurred on my system, and the original batch file I posted here didn't fix it. I looked to see if a DLL was missing and found this one. Adding it solved the problem. I also removed the line registering msxml3.dll since it didn't seem necessary. -sc]]
Now open a DOS box and navigate to your desktop, where the batch file is. (If you don't know where your desktop is in the directory structure, then just put the file somewhere you can find - it doesn't matter where you put it.) To execute the batch file, just type the file name at the command prompt (WU5_FIX). Answer "yes" or "okay" to any prompts. Now try Windows Update again. I'll bet it works. This fixed it for me, and I'd tried everything under the sun before this.
This solution is not in any Microsoft Knowledgebase article I've seen (and I've read over a dozen on the topic), nor did the Microsoft Tech Support person I've been corresponding with suggest it. I found pieces of this solution in different forum posts on the internet, and I'm posting it here because it was such a pain in the neck to find. I hope this information helps someone else with the same problem. There are too many critical vulnerabilities in Windows to not have access to Windows Update!
Please post if this fix works for you - I'm curious.
April 08, 2004
Creating an Online Store
To select wisely from the blizzard of options, you must understand the basics.
-----------
This is an expanded version of my article in PC Magazine on creating an online store, posted here due to popular demand. I received many requests from readers for additional information.
-----------
Online stores have become an essential element of doing business, but selecting wisely from the blizzard of options is difficult without an understanding of the basics. Depending on your choice, you can pay anywhere from 2% to 20% of each sale, not to mention monthly, annual, and startup fees.
Many businesses overpay for e-commerce services because the options are so confusing. A provider with a turnkey solution can be very appealing, despite a high price. The merchant may not even realize how high the price is compared to other options.
To make a good choice, businesses must first understand how online credit card processing works. Every online store needs two basic components: (1) a catalog to display products and allow customers to make selections, and (2) a method of accepting payment. These components are sometimes bundled together and sometimes sold separately, and costs vary widely.
Creating an Online Store
An online catalog can be as simple as a one page product list with each entry containing a "Buy now" button. If you have just one or two products, this is sufficient. But if you want customers to be able to select more than one product at a time, you have two choices.
The simpler method is a multi-product order page that lets customers enter quantities next to each item in your catalog. A single button labeled "Check out" finalizes the selections and brings customers to the payment page. Selections cannot be changed at this point without starting over.
If your online store contains a large number of products, you'll probably want to use a catalog with a "shopping cart" that can remember customers' selections as they browse your site. With a shopping cart, customers can click a "Continue shopping" button on the check out page to return to the catalog and add new selections without losing previous selections.
If you have programming skills, you can write your own custom e-store and shopping cart. Another option is to use a general purchase cart program such as osCommerce (an open source cart written in PHP), or Miva (a commercial product written in a proprietary scripting language). Both are frequently pre-installed with e-commerce hosting plans.
Hosting plans described as "commercial" usually often include support for Secure Socket Layers (SSL). This is for creating the secure form where customers enter credit card numbers. Handling credit card numbers securely takes knowledge and skill, so you may prefer to host the secure page on the site that processes your payments (more on this later). If you don’t plan to host the secure order page, don’t pay the additional fee for SSL.
Some Web hosts offer special e-commerce accounts with proprietary shopping carts that include editing tools for easy configuration. They are preconfigured to securely handle credit card transactions, but you are still responsible for obtaining an account (such as a merchant account) for accepting payment.
Two examples of e-commerce hosts are Yahoo Shopping (smallbusiness.yahoo.com/merchant/) and Mainstreet Stores (a Digital River company, mybiz.mainstreet-stores.com). Yahoo's Standard plan is a hefty $99.95 per month, plus 1% per transaction. This is in addition to the fees for processing payments. Main Street Stores is less expensive, but also less flexible in configuring the store’s appearance.
Accepting Online Payments
There are three main options for accepting payments online: (1) person-to-person (P2P) services such as PayPal or Yahoo PayDirect, (2) payment services that accept credit cards on your behalf, or (3) your own merchant account for accepting credit cards.
P2P services are low cost (PayPal charges just 2.2-2.9% of each sale plus $0.30), but usually require the buyer to register with the service, and this can be a barrier to sales. (PayPal just introduced a credit card service that doesn't require preregistration.) The registration process is time consuming, and some people prefer not to have their financial information kept on file.
Payment services are basically resellers. Their payment pages clearly state that they are the actual seller while you are only the supplier of goods and services. This disclosure gets around card association rules that forbid a company from accepting credit cards on behalf of another company. Costs can vary from 5-20% of each sale, sometimes with additional fees.
The traditional way to accept credit card payments is to obtain a merchant account. Merchant accounts have lower transaction fees than payment services (usually about 3%), but their service fees tend to be higher ($10-60 per month). There is usually a $200-300 application fee followed by a background and credit screen. Also, there’s usually a minimum term. If your business hits a slow patch, you won’t be able to cancel the merchant account.
Merchant accounts for internet-based businesses have higher fees and are harder to obtain because they’re higher risk. At one time, it was impossible to get a merchant account with a mainstream bank if your business was home-based, low-volume, a startup with no history, or based outside the US.
Large full-service banks still charge high setup and monthly fees, and are unlikely to approve an internet-based startup. But today there are banks that specialize in providing credit card services for small internet businesses. Approval rates are higher and prices are lower. Still, some small or non-US businesses may not be able to obtain a merchant account.
You’ll find companies on the internet offering merchant accounts to anyone, regardless of credit history, but beware sites like this. If the company isn’t following card association rules, it may be shut down at any time, leaving you high and dry.
For US businesses, Electronic Clearing House (echo-inc.com) and PayQuake (payquake.com) offer very low cost merchant accounts with a high percent of applicants accepted. If you’re outside the US, WorldPay (worldpay.com) is a good choice, though their prices are higher. See the "Merchant Accounts" section for details.
P2P Payment Services
Most online purchases are made by credit card in the US, but credit cards are less popular overseas. P2P services offer bank transfers and e-checks in addition to credit cards, and are the cheapest and easiest alternative.
PayPal isn’t the only P2P service, but it’s the largest and best known, and has high trust and acceptance among customers. Some many merchants, however, claim that PayPal freezes money in an account if there's any kind of customer complaint, whether founded or unfounded.
Since some people prefer credit cards and some prefer person-to-person services, it's a good idea to offer both options on your Web site. This has the added benefit of providing a backup in case one of the processors is offline.
Third Party Payment Processors
Even if you can get a merchant account, you may not want one for a startup because of the fixed costs. The alternative is to contract with a third party to sell your products using their merchant account. Companies providing this service are usually called third party processors, but most prefer the term "reseller".
It’s against card association rules to accept credit cards on behalf of another business since it allows the other business to avoid background and credit checks. However, there are no rules against being a reseller. You are the provider of goods and services, while the company with the merchant account is the actual seller.
The reseller arrangement must be clearly indicated on the order form to meet legal requirements, and prepare customers to see the reseller’s name on their credit card statement. If a customer doesn’t recognize a charge and calls her bank to dispute it (termed a "chargeback"), the merchant’s credit rating will be adversely affected.
At minimum, third party processors provide a shopping cart or product selection form, a secure order page, access to a payment gateway (more on this later), and use of a merchant account. Transaction rates generally vary from 6-20%, compared to 2-3% for a standard internet merchant account.
The cheapest and most flexible of these services are archrivals 2CheckOut and PaySystems. Both charge a $49 setup fee. 2CheckOut’s transaction fees are 5.5% of the purchase plus $0.45. 5% of purchases is held for 90 days on a rolling basis to use against chargebacks. PaySystems offers two rate plans: 3.95% plus $1, or $5.5 plus $0.35 with up to 5% of sales held for six months on a rolling basis.
Both offer a shopping cart, but you don’t have to use it. You can implement the cart on your own site, and use the services only for payment of the total. PayPal also can be used this way, but the other third party credit card processors require you to use their internal catalogs.
Another feature offered by PayPal, 2CheckOut, and PaySystems, but none of the other third party credit card processors is the ability to post purchase information back to a script on your site. This allows you to store order information in a database, and send an automated message to customers after verifying payment - for example, a software registration code.
PayPal and 2CheckOut post back instantly, while with PaySystems there's a 2-3 hour delay for fraud screening. PayPal doesn’t require fraud screening because the money is in hand, but 2CheckOut does, and it’s disconcerting to receive fraud alerts after your script has already mailed out software registration codes. 2CheckOut is aware of this problem and is working on a solution.
There are a few other differences. 2CheckOut allows you to customize the order form with a header and footer so the look matches your own site. PaySystems' checkout page is visually aggressive and there is no ability to customize it. 2CheckOut allows you to add your company’s name to the descriptor line on the customer's credit card bill, while PaySystems does not.
Also, to avoid liability beyond the purchase price, PaySystems checkout page insists that it sells only "PaySystem points" that are redeemable for products or services, but does not sell the actual products or services themselves. They are the only third party processor to describe themselves as a third party processor rather than a reseller. The point message on the checkout page is confusing, and may make some customers uncomfortable.
PaySystems also has some image problems because they handle credit card processing for quite a few scammers and spammers - for example, vendors selling penis enlargement pills. PaySystems says they will shut down any account after two complaints for spamming, but few people think to complain to a company's credit card processor, and their support of these companies has tarnished their reputation. For example, one Web site devoted to monitoring internet scams warns that sites using PaySystems to process credit cards are more likely to be scams.
Both 2CheckOut and PaySystems have been victimized in the rash of Distributed Denial of Service (DDoS) attacks over the last year. PaySystems moved to a distributed network with redundancy to protect against such attacks. 2CheckOut did the same after a particular devastating attack over Thanksgiving weekend in 2003.
All the other third party credit card processors cost more and are less flexible, but sometimes offer special features related to specific industries. For example, the shareware processor RegNow (regnow.com, owned by Digital River) charges an astronomical 20% transaction fee, but gives access to affiliate programs for increasing sales, and optionally will host downloads for a penny a megabyte.
ClickBank (www.clickbank.com) also offers an affiliate program. Products are restricted to digital goods and services that can be delivered over the internet. Also, only one product can be purchased at a time - you can't set up a list of products. There’s a $49 activation fee; the transaction fee is 7.5% plus $1.
Kagi (www.kagi.com) allows both tangible and digital goods and services, with a product list rather than a shopping cart. There are no setup or monthly fees. Transaction fees but average around 8-10%.
The only other third party processor offering a shopping cart is CCNow, a Digital River service that is restricted to tangible goods. Use of the shopping cart is required. The cost is $9.95 per month ($11.95 outside the US), plus 9% for sales in excess of $100 (11% outside the US).
Secure Forms & Gateways
The trickiest part of creating an online store is accepting payment because you have to securely obtain the customer's credit card, and then securely transmit it for processing. Whether you want to obtain authorization immediately or enter the credit card manually when you fill the order, the information must be encrypted during data entry and subsequent transmission.
To secure a Web page for entry of a credit card number you need an SSL certificate from a recognized certificate authority. GoDaddy (godaddy.com) recently started offering very low priced SSL certificates. GoDaddy offers only standard certificates and not "step-up" certificates.
Step-up certificates will automatically increase the encryption strength supported by the customer's browser to 128-bits if necessary. All modern browsers support 128-bit encryption, but until recently the US disallowed export of strong encryption so many people overseas still have 40-bit and 56-bit browsers. If few of your customers are overseas, this may not matter.
To authorize credit card charges in real time, you need a "payment gateway" in addition to an internet merchant account. A payment gateway is the internet equivalent of the in-store swipe terminal.
Payment gateways are servers that have been licensed to send encrypted financial transactions to the card processing network, which is separate from the internet. An in-store terminal gets the transaction data from the cash register and the credit card; a payment gateway gets transaction data from an encrypted online payment form.
The payment form must send data to the gateway according to detailed rules, so implementation requires some programming. Since errors can compromise security, gateway providers encourage merchants to use a secure form hosted on the gateway server, rather than hosting the form on their own server. The form's appearance can be customized to some extent, but the merchant won't be able to retain the customer's credit card number, making it difficult to identify chargebacks (disputed charges).
Another solution is to use shopping cart software with built-in gateway support. No shopping cart supports all gateways, so choose the shopping cart first, and then choose from its list of supported gateways. There are also multiple processing networks, and no gateway supports them all. Your merchant account must be with a bank that uses a network supported by your gateway.
Merchant Accounts
To process credit cards, you need both a merchant account and a gateway service. The gateway service is usually provided by a third party for a separate fee, but not always.
Electronic Clearing House, Inc. (echo-inc.com), has their own gateway and processing service, so they can offer a free gateway with their very low cost merchant accounts. Merchants can accept e-checks in addition to credit cards. The setup fee is $99, and the monthly fee of $19.95 is charged only if there are sales in that month. Discount rates are 2.1-2.6%.
PayQuake (www.payquake.com) is another low-cost merchant account provider with a good track record. The Pay for Play plan has an annual fee of $49, and a discount rate of 3.79% plus a $0.50 transaction fee. Plans for higher volume businesses include setup and monthly fees, but lower rates for each purchase -discount rates of 2.4-2.8% plus $0.30-0.40 per transaction.
Both Echo and PayQuake offer merchant accounts only to US businesses. If you’re outside the US, WorldPay is a good choice, though their prices are somewhat higher.
WorldPay’s WorldDirect service offers a similar range of features as 2CheckOut and PayPal, so many people erroneously believe they are third party processors. In fact, WorldPay offers standard merchant accounts with an array of services usually associated with third party processors. Transaction fees are just 2.95% plus $0.45, but there is a $299 setup fee, plus a monthly fee of $35/month.
Making a Choice
There are dozens of other companies offering ways to accept money on a Web site - P2P services, low-cost/no-screen merchant accounts, wire transfers, and even an electronic currency based on a store of gold bullion. Since money is involved, scammers abound. Check out a company carefully before giving them your business. Simply typing the company’s name into a search engine with the word "forum" or "problem" can turn up valuable information. If an offer sounds too good to be true, it probably is.
Hiring a consultant to set up your online store may be cheaper in the long run than paying high ongoing service and transaction fees. In general, the more work you’re willing to do upfront, the less you’ll pay for the privilege of selling goods and services online.
March 26, 2004
For Developers: How to Get Crash Reports on Win9x/2000
My article on XP's Windows Error Reporting system for O'Reilly's WindowsDevCenter.com was targeted towards end-users, so a developer section on how to get crash reports on non-XP systems didn't really fit. Still, it's interesting for developers, so here is the section that was cut. For background, please refer to the published article.
Crash Reports on non-XP Systems
WER was introduced with Windows XP, and also runs on Windows Server 2003. The system files that implement WER are not redistributable because they rely on kernel and global exception handling code that is specific to XP. Microsoft will support WER on future versions of Windows, but has no plans to retrofit it for older versions. The reason that Office XP and Explorer can produce crash reports on back versions of Windows is that they use a custom crash report system that pre-dates WER.
Developers writing for older operating systems can't use WER for crash reports, but they can use an elegant replacement called XCrashReport, written by software consultant Hans Dietrich. XCrashReport was published on Code Project in a series of four articles. The first article describes how to find bugs using release-mode crash reports. The second and third describe some additional techniques. The fourth article contains the utility for generating crash reports and prompting users to send them back to the developer:
http://www.codeproject.com/debug/XCrashReportPt1.asp
http://www.codeproject.com/debug/XCrashReportPt2.asp
http://www.codeproject.com/debug/XCrashReportPt3.asp
http://www.codeproject.com/debug/XCrashReportPt4.asp
XCrashReport uses a redistributable, backward-compatible XP library called dbghelp.dll to produce mini-dumps. It also captures exception information, register values, stack data, and a list of the modules loaded at the time of the crash (all data that WER collects as well). Programmers can optionally add to the report any registry keys that might help diagnose the cause of the crash. End-users can review the contents of the error report files before deciding whether to submit them.
If the user agrees to send the crash report, the files are zipped up and sent through unencrypted email directly to the software developer. They are not added to the WER database on Microsoft's server. Some end-users may feel more comfortable sending the files directly to the programmer, but as you'll see in the next section, there are some compelling advantages for both the end-user and developer to using Microsoft's tightly protected, carefully monitored, and usefully organized central repository.
XCrashReport isn't suitable for use with programs that have a large user base since the number of XCrashReport emails that a company receives could quickly become overwhelming. But for small developers writing software for pre-XP versions of Windows, XCrashReport is a good solution. Also, shareware developers operating on a budget will be relieved at not having to purchase a VeriSign ID (a requirement for accessing the WER system).
March 22, 2004
How to Install Movable Type
The Web Log you are now reading was created with a server-based publishing system called Movable Type. Installing server-based software isn't difficult, but it requires many more manual steps than installing a program on your local computer. Before you can run an installation script, you must first put the files in the correct places on the server, set the correct permissions, manually create any necessary databases, and correctly specify configuration parameters.
This is not hard to do if the software comes with precise, complete, and clearly written instructions. But unfortunately, the Movable Type installation docs are not as good as the software itself. So my first blog entry is a tutorial on how to install Movable Type, focusing on the parts that were unclear to me when I was doing it.
My installation of Movable Type is on a Linux server with a MySQL database. If there are issues with other operating systems or databases, they won't be addressed here. But most of what I describe here will be relevant across platforms.
I'll start with a list of what files go where (a directory structure that works) and the necessary permissions for the various files. Don't forget to upload files in the correct mode:
- Everything except the bitmaps must be uploaded in ASCII mode.
- The bitmaps must be uploaded in BINARY mode.
If you don't upload things in the correct mode, the scripts won't run and the bitmaps won't display.
Directory Structure
You will have two Movable Type directories, one containing the program and the other containing the data (your blog entries, and the Movable Type documentation and bitmaps). You need two directories because only script files can go in cgi-bin. Files stored in cgi-bin cannot be viewed or downloaded by visitors, only executed. Don't be tempted to put the entire installation outside cgi-bin because the limitations are a security feature.
The directories listed below are described relative to the Web site's home directory. For example, the directory /cgi-bin/ corresponds to a URL like http://www.domain.com/cgi-bin/. When you configure Movable Type, you will need to know the server path to this home directory. If this information isn't in your server's control panel, ask your Web host administrator what it is.
Beneath each directory name is a list of what it contains, followed by notes.
Program directory: /cgi-bin/movabletype/
- all files with this filespec: mt*.cgi
- the configuration file: mt.cfg
- these folders: extlib, import, lib, schemas, search_templates, tmpl
Notes:
Set the permissions for all the CGI files to 755.
The "import" directory is something you create; it's not in the distribution zip.
The "extlib" directory will only contain extensions not already installed on your server, so don't upload any files or folder to this yet. Just create an empty directory with this name and read on.
Data directory: /movabletype/
- these folders (you manually create them): archives, mt-static
Notes:
The /movabletype/ directory is where current blog entries are stored. Archives are stored in /movabletype/archives/. The Movable Type documentation and bitmaps are stored in /movabletype/mt-static/.
The folders containing blog entries must be writable by the world, so the permissions for /movabletype/, /movabletype/archives/, and all the files within these folders must be set to 777 (full permissions), unless you have special security software running on the server. See the Movable Type documentation for details.
Movable Type docs and bitmaps: /movabletype/mt-static/
- these files: index.html, style.css
- these folders: docs, images
Notes:
The index.html file is mainly there to prevent visitors from viewing the contents of this directory. There is a link on this page to the Movable Type documentation.
The Two Files You Need to Edit
There are two configuration files you will need to edit:
- mt.cfg
- mt-db-pass.cgi
To configure your settings, you need to know:
- server path to your home directory
- server path to your sendmail program
- server path to Perl
- if there is anything in your MySQL installation that differs from the default
If this information isn't listed in your server's control panel, ask your Web host administrator.
The other thing you need to do before editing the configuration files is create an empty MySQL database (call it MovableType), and set up a username and password with full permission to access it. Don't use the same username and password you use to access your Web hosting account; set up a separate one.
Once you have all the information and have created the MySQL database, you are ready to edit mt.cfg. The comments in the file explain almost everything, with the exception of the database settings, which are described in the Movable Type installation docs.
The database section is near the top of the file and contains just one line: "DataSource ./db". Since you will be using a MySQL database, comment out this line (put a # sign in front of it) and add these three lines in its place:
ObjectDriver DBI::mysql
Database database_name
DBUser database_user
Replace database_name and database_user with the names you set up when you created the database. If you called your database MovableType as I suggested above, the database line will read:
Database MovableType
If your MySQL installation is different from the default in terms of hostname, port, or location of mysql.sock, then you will need one or more of these additional lines (default settings are shown here):
DBHost localhost
DBPort 3306
DBSocket /tmp/mysql.sock
After you've finished editing the database settings, go through the rest of mt.cfg slowly and methodically. Read each comment carefully and make a choice; do not skim. If you want the default setting, leave the line for that setting commented out. You only need to uncomment lines when you are changing the default.
When you're done editing mt.cfg, there is only one more change you need to make: edit the file mt-db-pass.cgi. This file contains a single word, "database_password", and nothing else. Replace "database_password" with your MySQL password. The password is stored in a separate file for security reasons.
Upload the two edited configuration files to the program directory on the server. If you uploaded these files before and set their permissions, you don't need to set them again.
How to Know Which of the extlib Files You Need
The files and folders in extlib are extensions that you may already have on your server. You only need to install the ones you don't have. To find out what you need, point your browser here: http://www.domain.com/cgi-bin/movabletype/mt-check.cgi. This script will check your server, and tell you which extension modules are missing.
In addition to what this script reported, I had to upload the subdirectories "I18N" and "Locale". I got error messages when they weren't there.
Run the Installation Script
Now all the files you need are on the server in the correct places, the correct permissions have been set, and the configuration parameters have been specified. So point your browser to this URL:
http://www.domain.com/cgi-bin/movabletype/mt-load.cgi
This script creates the initial Movable Type files, and sets up the database tables. After you have successfully run mt-load.cgi, delete it from the server. It is a serious security risk not to do this.
Configure Movable Type
Now you are ready to log into Movable Type for the first time so you can configure it. Point your browser here:
http://www.domain.com/cgi-bin/movabletype/mt.cgi
This is the administration area. Log in using the default username (Melody) and password (Nelson).
There are two configuration changes that are necessary. Everything else is optional:
- Edit the profile to change the username and password (that's for security).
- Edit the paths. For some reason, Movable Type does a poor job of guessing and they will be wrong. In general, the string "cgi-bin" should not be in there anywhere.
Now you have a working blog, though you will probably want to change the default appearance and settings. Most of the settings are clearly documented within the program except for the Templates area, which controls the appearance of your blog.
The style presets are not stored within the program itself. They are on the Movable Type Web site here:
http://www.movabletype.org/default_styles.shtml
Copy the style code you want from this page, then paste it into the edit box on the Templates page.
Before you make your blog live, test all the links. It's very easy to mess up the paths.
I hope this overview is helpful and saves you some time.