The error looks like this:

 error:14090086
 SSL routines:SSL3_GET_SERVER_CERTIFICATE
 certificate verify failed

Well, the problem has a very simple solution. CURL cannot talk directly to the Windows certificate repository, so you have to give it a file to validate the Trusted Root Certificate Authority against.

Follow these steps to export your Trusted Root Certificate Authority CA certs:

1. From the windows start menu, run the command “mmc.exe” to launch the Microsoft Management Console;
2. From the MMC, choose “File” > “Add/Remove Snap-in…” from the main menu;
3. Add the “Certificates” snap-in; When asked which certificates you want to manage, select “Computer Account” and “Local computer“;
4. from the console root, navigate to “Certificates (Local Computer)” > “Trusted Root Certification Authorities” > “Certificates“;
   
5. * Select all of the certificates (CTRL+A) and select “Action” > “All tasks” > “Export…” from the MMC main menu;
6. Follow the wizard to export the certificate(s) to the Cryptographic Message Syntax Standard – PKCS#7 (,pb7 file) to a file called “TrustedRootCAs.pb7“;
7. Open a command prompt (“cmd.exe“) and navigate to the folder containing the PB7 file you just created;
8. Run openSSL.exe (you may need to add the path to this program to the Windows PATH environment variable) to convert the file to text using the following command:
1. c:\php\extras\openssl\openssl.exe pkcs7 -inform DER -in TrustedRootCAs.pb7 -print_certs -text > TrustedRootCAs.certs
9. Then, in your PHP application, add the following line BEFORE you call curl_exec():
1. curl_setopt ($ch, CURLOPT_CAINFO, ‘C:\PHP\extras\openssl\TrustedRootCAs.certs’)

That’s about all you should need to get things rolling.

Remember, you don’t necessarily have to export all of the CA’s. In the case of Yubikey, the authentication API server uses a certificate issued by GoDaddy, so you only need export that single on if you prefer not to have to keep this file updated every time ROOT CA certificates are updated by the various providers.

So, you’re probably wondering how to fix it. You may have even tried adding some new firewall rules to Windows yourself to open up the data channel. Well, unfortunately that doesn’t quite fix the problem.

Background

For those of you who haven’t noticed, Microsoft have released a new version of the FTP services that have been completely re-written for Windows Server® 2008… FTP 7.5.
If you don’t have it already, you can download it from http://www.iis.net/.
Note that you must be running Windows Server 2008 with IIS7.
You can download the packages independently from here:

• FTP 7.5 for IIS 7 (x64)
• FTP 7.5 for IIS 7 (x86)

There’s a special setting in the Windows Firewall that you can’t configure (as far as I can determine) via the administration console. You need to get down to command-line options to tweak things a bit.

The following information is an excerpt from: http://learn.iis.net/page.aspx/309/configuring-ftp-firewall-settings/
It was exactly the information required to fix the access issues I was having with FTP services.

Note: You will need to make sure that you follow the steps in this section walk-through while logged in as an administrator. This can be accomplished by one of the following methods:

• Logging in to your server using the actual account named “Administrator”.
• Logging on using an account with administrator privileges and opening a command-prompt by right-clicking the Command Prompt menu item that is located in the Accessories menu for Windows programs and selecting “Run as administrator”.

One of the above steps is required because the User Account Control (UAC) security component in the Windows Vista and Windows Server 2008 operating systems prevents administrator access to your firewall settings. For more information about UAC, please see the following documentation:

• http://go.microsoft.com/fwlink/?LinkId=113664

Note: While Windows Firewall can be configured using the Windows Firewall applet in the Windows Control Panel, that utility does not have the required features to enable all of the features for FTP. The Windows Firewall with Advanced Security utility that is located under Administrative Tools in the Windows Control Panel has all of the required features to enable the FTP features, but in the interests of simplicity this walk-through will describe how to use the command-line Netsh.exe utility to configure the Windows Firewall.

Using Windows Firewall with non-secure FTP traffic

To configure Windows Firewall to allow non-secure FTP traffic, use the following steps:

1. Open a command prompt: click Start, then All Programs, then Accessories, then Command Prompt.
2. To open port 21 on the firewall, type the following syntax then hit enter:
   

   netsh advfirewall firewall add rule name="FTP (non-SSL)" action=allow protocol=TCP dir=in localport=21

3. To enable stateful FTP filtering that will dynamically open ports for data connections, type the following syntax then hit enter:
   

   netsh advfirewall set global StatefulFtp enable

Important Notes:

• Active FTP connections would not necessarily covered by the above rules; an outbound connection from port 20 would also need to be enabled on server. In addition, the FTP client machine would need to have its own firewall exceptions setup for inbound traffic.
• FTP over SSL (FTPS) will not be covered by these rules; the SSL negotiation will most likely fail because the Windows Firewall filter for stateful FTP inspection will not be able to parse encrypted data. (Some 3rd-party firewall filters recognize the beginning of SSL negotiation, e.g. AUTH SSL or AUTH TLS commands, and return an error to prevent SSL negotiation from starting.)

Using Windows Firewall with secure FTP over SSL (FTPS) traffic

The stateful FTP packet inspection in Windows Firewall will most likely prevent SSL from working because Windows Firewall filter for stateful FTP inspection will not be able to parse the encrypted traffic that would establish the data connection. Because of this behavior, you will need to configure your Windows Firewall settings for FTP differently if you intend to use FTP over SSL (FTPS). The easiest way to configure Windows Firewall to allow FTPS traffic is to list the FTP service on the inbound exception list. The full service name is the “Microsoft FTP Service”, and the short service name is “ftpsvc”. (The FTP service is hosted in a generic service process host (Svchost.exe) so it is not possible to put it on the exception list though a program exception.)

To configure Windows Firewall to allow secure FTP over SSL (FTPS) traffic, use the following steps:

1. Open a command prompt: click Start, then All Programs, then Accessories, then Command Prompt.
2. To configure the firewall to allow the FTP service to listen on all ports that it opens, type the following syntax then hit enter:
   

   netsh advfirewall firewall add rule name="FTP for IIS7" service=ftpsvc action=allow protocol=TCP dir=in

3. To disable stateful FTP filtering so that Windows Firewall will not block FTP traffic, type the following syntax then hit enter:
   

   netsh advfirewall set global StatefulFtp disable

I just got promoted.
One of my photos (well two actually) has just been used to promote the home page of the Photo Art Gallery (a.k.a. PhArt Gallery)

Come see my complete portfolio here: http://www.photoartgallery.com/artist/doublehelix

The rest of my work can of course be found here: http://www.redbubble.com/people/doublehelix

Here are some shots from the show:

Here are some shots from the trip… enjoy.

At the core of this issue is a simple malconfiguration of the MSI installer that performs the update and configures the registry. It seems that as the installer creates or modifies executeable files and/or registry keys, it does so as the administrator user. This in turn cases all of the permissions on those files/keys to reset to those of the administrator user, causing the error you see.

Specifically, Update KB951944for Office 2007 seems to be the update causing the issue (according to user who have tested each and every patch for the bug). Skipping this one should avoid the problem all together.

There are several possible resolutions to this problem depending on your specific situation, some simple to solve, some more difficult.

The most obvious, and easiest fo resolve, is permissions on the executable files themselves. Firstly you have to open the Office application folder (normally “C:Program files (x86) Microsoft OfficeOffice 12″ or similar). You’ll need to locate each individual application executable (e.g. “Word” is “winword.exe“.) Right click on the executeable and select the “Properties” menu. In the properties window that opens, select the “Security” tab and click “Edit“. Give “Users” full control. You’ll may (in rare cases) need to re-create your shortcuts from these files.

Amongst the registry keys that are affected are the following:

• HKLMSoftwareMicrosoftWindowsCurrentVersionInstallerUserDataS-1-5-18Components379E92CC2CB71D119A12000A9CE1A22A
• HKLMSoftwareMicrosoftWindowsCurrentVersionInstallerUserDataS-1-5-18ComponentsDA42BC89BF25F5BD0AF18C3B9B1A1EE8
• HKLMSoftwareMicrosoftWindowsCurrentVersionInstallerUserDataS-1-5-18ComponentsDA42BC89BF25F5BD0BF18C3B9B1A1EE8
• HKLMSoftwareMicrosoftWindowsCurrentVersionInstallerUserDataS-1-5-18ComponentsDA42BC89BF25F5BD0CF18C3B9B1A1EE8
• HKLMSoftwareMicrosoftWindowsCurrentVersionInstallerUserDataS-1-5-18Components82DE7549CF3F8CCB0DF18C3B9B1A1EE8
• HKLMSoftwareMicrosoftWindowsCurrentVersionInstallerUserDataS-1-5-18Components6F949E36CB3004C50AF18C3B9B1A1EE8
• HKLMSoftwareMicrosoftWindowsCurrentVersionInstallerUserDataS-1-5-18Components6F949E36CB3004C50CF18C3B9B1A1EE8
• HKLMSoftwareMicrosoftWindowsCurrentVersionInstallerUserDataS-1-5-18Components7AA6F3DBF3CE139469FE63D56E7AF446

Any (including any that may not be listed above yet simmilarly afflicted) registry affected in this manner keys need to have thier permissions reset to the same permissions as thier parent key. i.e permissions should be inherited.
If you’re not comfortable doing this by hand, there’s an open-source utility called SetACL (http://setacl.sourceforge.net/) that can help.

WARNING: There are many keys under the “components” key that have nothing to do with Office! do not go and arbitrarily go and reset every single sub-key under “components” to inherited permissions, as this will effectively remove all UAC protection from all installed components (not just office) so don’t do that! You’ll have to inspect individual registry keys.

If you’re in fact going to use SetACL, you can execure the appropriate command-line function like this:

setacl -ot reg -on "HKLMSoftwareMicrosoftWindowsCurrentVersionIn stallerUserDataS-1-5-18Components{GUID}" -actn setprot -op "dacl:np;sacl:nc" -rec yes

Where {GUID} is the ID of the component that requires resetting. It may be easier to copy this command into a batch file if you need to execute it numerous times. Typing this over and over 30 times can be painful.

Well, hopefully one of these solutions has solved the problem fo you. If not, I’ve heard of a later update causing almost the same issue, so you may very well be experiencing a similar problem! Let me know if you do… especially if you figure out another way to solve it.

Thanks to everyone at VistaHeads for following up the problem.

For more information, and to join in discussions on Microsoft products, see the following Microsoft specific Newsgroups:
microsoft.public.office.misc and microsoft.public.word.newusers

But what if you don’t want your list of values to be able to be altered at run-time? You need them to be contained in a constant rather than a variable.

Example: to declare an array of abbreviated week names:

const
  Days: Array[0..6] of String = (
      'Sun', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat'
  );

You could then access each name by the index of the day of the week within the Days constant.

i := DayOfWeek(Date); //returns an integer 0-6
ShowMessage('Today is  ' + Days[i]);

Another common use for constant arrays is to describe the values in an ENUM type:

type
  TStatusCodes = [
    scUnknown, scActive, scPending,
    scDisabled, scSuspended
  ];
const
  StatusString = Array[TStatusCodes] of String = (
    'Unknown', 'Active', 'Pending',
    'Disabled', 'Suspended'
  );

Then, the description string for each status code becomes available via the ordinal value of the status code itself:

ShowMessage('Your account is '+ StatusString[scActive]);

Would show a message box with the text “Your account is Active“. Of course in the real world, the status code enumeration value would come from a user object or some such similar method (like “function getAccountStatus(): TStatusCode;” perhaps).

Option 1:

1. Go to “Start” -> “Run“.
2. Write “cmd” and press on “Enter” key.
3. Write the command “net statistics server” and press on “Enter” key.
4. The line that start with “Statistics since …” provides the time that the server was up from.

* The command “net stats srv” can be use instead.

Option 2:

The Uptime.exe tool allows you to estimate Server Availability with Windows NT 4.0 SP4 or Higher.

Uptime.exe is a standalone program. To install the tool, simply copy the file into your Windows directory. You may then run the tool at a command prompt.

For extended help on this tool, type the following at a command prompt:

uptime /help

This tool is most accurate when run with administrator privileges, however, even without administrator privileges, the tool attempts to make a best estimate based on available information. In all cases, the results should be considered estimates.

The uptime.exe program can be downloaded from Microsoft here:
http://download.microsoft.com/download/winntsrv40/install/uptime_1.01/nt4/en-us/uptime.exe

See also:

http://support.microsoft.com/kb/555737
http://support.microsoft.com/kb/232243

java.io.FileNotFoundException: C:\Documents and Settings\ReleaseEngineer.MACROVISION\Application Data\Azureus\azureus.config.saving (The system cannot find the path specified)

or
error:failed to create directory C:\Documents and Settings\ReleaseEngineer.MACROVISION\Application Data\Azureus\azureus.config.saving (The system cannot find the path specified)

Well, it seems that some genius programmer, instead of using the WIN32 function to determine the users application data path, has instead hard coded one assuming that the user will be running Windows XP under which creating the above directories might be allowed as all users are super users by default (under normal home-use circumstances).

Well, there is a solution – however it involves editing the Windows Registry.
NOTE: If you’re unsure about what this means or are uncomfortable with editing the Windows Registry directly, ask for help from someone who has, or do a lot of research before you begin. If you break or corrupt your registry, windows may very easily become unusable.

Open your registry editor by running RegEdit from the windows “RUN” command:

Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folder

and make sure that AppData is set to “C:\Users\<user>\AppData\Roaming“. (replacing <user> with your local user account name – check the path yourself if unsure).

Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folder

AppData should be “%USERPROFILE%\AppData\Roaming”

Computer\HKEY_CURRENT_USER\Volatile Environment

AppData should be “C:\Users\<user>\AppData\Roaming” (again, replacing <user> with your local user account name – check the path yourself if unsure).

This should solve most of your issues.

I’ve been told that DELETING any registry keys containing the value: “C:\Documents and Settings\ReleaseEngineer.MACROVISION” will also work as the keys will be re-created automatically using default values (the correct default values) the next time a program saves its settings. However, this seems a drastic and possibly unsafe step, so leave it as a last resort if you’re still having problems.

Hope this help you all.

Internet Explorer, for the most part, implements MSXml 4.0 or higher. However that’s (obviously) a Microsoft technology, and the standard implementation doesn’t support XPath in the DOM.

In particular the selectNodes() and selectSingleNode() functions are of particular use when manipulating XML or the DOM. Using these functions you can parse an XPath expression and get a nodelist of elements in your DOM that match the expression.

The code below adds basic XPath parsing functionality to the DOM in Mozilla. (Thanks to km0ti0n)

// mozXPath - http://km0.la/js/mozXPath/
// km0ti0n@gmail.com
// Code licensed under Creative Commons Attribution-ShareAlike License
// http://creativecommons.org/licenses/by-sa/2.5/
if (document.implementation.hasFeature("XPath", "3.0")) {
	if ( typeof XMLDocument == "undefined" ) {
		XMLDocument = Document;
	}
	XMLDocument.prototype.selectNodes = function(cXPathString, xNode) {
		if ( !xNode ) { xNode = this; }
		var oNSResolver = this.createNSResolver(this.documentElement);
		var aItems = this.evaluate(cXPathString, xNode, oNSResolver, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
		var aResult = [];
		for ( var i = 0; i < aItems.snapshotLength; i++) {
			aResult[i] =  aItems.snapshotItem(i);
		}
		return aResult;
	}
	XMLDocument.prototype.selectSingleNode = function(cXPathString, xNode) {
		if( !xNode ) { xNode = this; }
		var xItems = this.selectNodes(cXPathString, xNode);
		if ( xItems.length > 0 ) { return xItems[0]; }
		else { return null; }
	}

	Element.prototype.selectNodes = function(cXPathString) {
		if (this.ownerDocument.selectNodes) {
			return this.ownerDocument.selectNodes(cXPathString, this);
		} else { throw "For XML Elements Only"; }
	}

	Element.prototype.selectSingleNode = function(cXPathString) {
		if (this.ownerDocument.selectSingleNode) {
			return this.ownerDocument.selectSingleNode(cXPathString, this);
		} else { throw "For XML Elements Only"; }
	}
}

It appears that Opera doesn’t have the XMLDocument object type, so, when using the XmlHttpRequest object the responseXML is in fact a Document object.

To get around this fact, we can use:

if ( typeof XMLDocument == "undefined" ) {
    XMLDocument = Document;
}

To use these new features, in either IE or Firefox, you can now simple call the functions as a method of the elements themselves… e.g.:

On the following XML Document:

    
      Some Content
    
    
      Some Content
    
    
      Some Content
    

For the XML sample above, you can use the following XPath to select all ContentNode‘s with their enabled attribute set to “true”:
//subnode[@enabled='true']/contentnode

So you would retrieve your XML Node List by executing the following JavaScript function:

//assume the variable xDOM is an XmlDocument object
//...that has been pre-loaded with the example XML
var nodeList = xDOM.selectNodes('//subnode[@enabled='true']/contentnode');
for each (var xNode in nodeList) {
    //do some operation...
}

This would perform some operation on each contentnode which is inside a subnode with it’s enabled property set to true.

NOTE: Be sure to double check your syntax, spelling and remember XML/XPath is CaseSensitive.