First you need to have a server that is running VNC, but most likely only has it’s SSH port exposed. I’ll assume that SSH is on port 22 and VNC is on port 5900 (these are the default ports for these services). I’ll also assume that you have the ssh command and a VNC client installed on your client machine.

1. On your client machine, open a command line window and enter the following to create the SSH tunnel:

ssh -N -p 22 USERNAME@YOURSERVER -L 5901/localhost/5900

Replace USERNAME with your server username, and replace YOURSERVER with your server address (ie verysimple.com or 192.168.1.99)

2. Once you enter this command you’ll be prompted for the server password. Enter the password. You will see no feedback in the terminal window, but the SSH tunnel is now active.

3. Open your VNC client and connect to the address “localhost:5901″ If you have a password set for VNC access then you will need to enter that now. If all goes well, you should see your server VNC desktop!

It might seem weird that you are connecting to localhost in your VNC client. But the the SSH tunnel you created is actually routing port 5901 on your localhost to port 5900 on your server.

The app is called LogFileMonitor and it’s available at google code.  You can download a Windows binary or the full source (GPL3) at http://code.google.com/p/logfilemonitor/.  A screenshot and feature list are on the google code page.

If you’re a software developer and have any interest in participating, drop me a line.  It would be nice to have a Mono port so the app can run on any OS.  Currently it only runs on Windows.

Starting with Windows Visa several types of links are supported including symbolic links using the command mlink. You can create them with a simple DOS command, however there is one trick – you must create the link as administrator. If you do not run the command as Administrator, you will get an error “You do not have sufficient privilege to perform this operation”

To create a symbolic link in Vista:

Go to Start Menu -> Accessories -> Command Prompt and RIGHT-click the icon. Select “Run as administrator” from the dialog menu. This will open a command prompt window that is running with full administrator permissions. In this window, use the following command to create a symbolic link:

mklink /d c:\mylink c:\sourcefolder

(The /d switch is used for directories. If you are linking a single file, you don’t need the /d.)

To delete links, simply use Windows Explorer. Interestingly you don’t need to run Explorer as administrator, just delete ‘em as you would any file or folder.

Steps to Fix the Problem:

Before you troubleshoot further, you may want to read #5 about how the Application Pool effects PHP configuration changes.

1. Replace the old DOS format path to the PHP Executable with a full path w/ quotes
2. Move php.ini to C:\Windows
3. Edit php.ini to set cgi.force_redirect = 0 (only necessary for CGI mode)
4. Make sure php-cgi.exe and/or phpisapi.dll are included in Web Service Extensions
5. Recycle the Application Pool

1. Replace the old DOS Path Format

The default path to PHP is C:\Program Files\PHP. When creating the IIS extention mapping, the PHP Installer uses the old DOS format path to the PHP ISAPI or CGI executable such as “C:\PROGRA~1\PHP\PHP5IS~1.DLL”. IIS does not seem to like this format.

One simple solution for this is to simply reinstall PHP to C:\PHP, or another location that doesn’t use long filenames. This will generally save you a lot of grief as PHP and its installer do not seem to handle windows long file names consistently.

If you prefer to keep things in Program files, go to the IIS Extension Mapping screen and locate the value for “.php” (See screenshot above). Click the browse button, select the executable and put quotes around it the entire path. So the value for this field should look like this “C:\Program Files\PHP\php5isapi.dll” (WITH the quotes around it). If you have installed PHP in CGI mode instead, the file name would be php-cgi.exe instead of php5isapi.dll

While you’re at it you may want to check the box for “Verify that file exists” as well. This allows IIS to handle actual missing pages (ie broken links) and return a 404. Otherwise IIS will just pass the request to PHP without verifying the .php file really exists and PHP throws a CGI error when the file isn’t found. People seem to have inconsistent results with this setting.

If you recycle the app pool at this point (see step #5) you *may* solve the 404 error depending on what extensions you installed or whether you had re-run the installer and changed stuff. However, you may still have issues changing php.ini settings in which case keep reading.

2. Copy php.ini to C:\Windows

The PHP installer creates a php.ini file for you based on your selections in the setup process. However the installer saves the file in C:\Program Files\PHP. The problem is that PHP is looking in C:\Windows for the .ini file. So, you need to move the file php.ini to C:\Windows. This may be confusing because PHP seems to run fine. But if you look closely at the phpinfo() output, you may find that php.ini file is not being loaded and all default settings are being used.

One of the critical things when configuring PHP is to actually edit the .ini file that is being used by PHP. The installer creates a worthless file in a location that PHP won’t read and so you may waste a lot of time editing this file. PHP pretty much universally will check the Windows folder for php.ini on all varieties of Windows, so my advice is to use that location and delete any other php.ini files that are hanging around..

3. Set cgi.force_redirect = 0 (Only necessary for CGI mode)

Various people report that you need to edit php.ini and set:

cgi.force_redirect = 0

I haven’t noticed this setting having any effect on my installations, but many people claim it is necessary when you are running PHP in CGI mode. This setting will have no effect if you are running in ISAPI mode.

4. Make sure php-cgi.exe and/or phpisapi.dll are enabled in Web Service Extensions

In IIS Manager, click on “Web Service Extensions” This includes a list of all dll and exe files that IIS is allowed to execute. The extension mapping that is specified for .php files must also be added here. I prefer to just add both php-cgi.exe as well as php5isapi.dll here and enable them both so that if I don’t need to worry about it again.

If the handler is already in the list, make sure that it is “enabled” as well. The enabled services have a green overlay on the service icon.

Lastly, confirm that the file path is exactly the same here as it is in your .php extension mapping configuration. That includes the dos path formatting. If you use junctions, you need to be using the same path in both places. IIS seems to check the path rather than the executable. It will not recognize if you use a slightly different path, even if they both point to the same executable.

5. Recycle the Application Pool

In order for any PHP configuration changes to take effect in Windows 2003, you need to recycle the Application Pool. If you have made changes to php.ini and they don’t seem to take effect, this is likely the reason. Among other things, the pool caches PHP settings and you need to clear it before new configuration settings will take effect. You’ll read people telling you to restart IIS (which doesn’t recycle the app pool) or even reboot your machine (which is overkill). You don’t need to do either of those. Just right-click on the DefaultAppPool in the IIS management interface and “Recycle” is one of the options.

If I’m having trouble with the ini file, I like to have a typical phpinfo.php file on the server while I make some arbitrary change to the php.ini file (like the session timeout or the max upload size). I refresh phpinfo.php and verify that my changes are taking effect. You can also check the Windows Event logs under “System” which will sometimes report errors in the php.ini file.

Notes regarding re-running the PHP installer to make changes:

The PHP installer does not really handle changes all that well. For one thing it will overwrite the path to the PHP executable w/ the old DOS format so you need to fix that after you run it.

The 2nd thing is that it will write changes to C:\Program Files\PHP\php.ini – regardless of the fact that PHP is actually looking at C:\Windows\php.ini

If you had previously moved php.ini to the windows folder, when you run the Change installation feature, it will create a fresh php.ini file that only incorporates the most recent changes. (ie, if you had 10 extensions enabled and you make a change to enable 1 more, your new php.ini file will only have the 1 enabled and the previous 10 will no longer be enabled)

One way around this is to temporarily move C:\Windows\php.ini file to C:\Program Files\PHP. Then run in installer to make changes. The installer will write changes to php.ini in that location. Then, move php.ini back to C:\Windows.

The machine itself is huge, heavy and requires three power cords to run. It’s also extremely loud. Though it was a mighty workhorse in it’s day, now there are cellphones and PDAs that would give it’s CPU a run for it’s money. I thought the hardware was so old that it would make sense to migrate the whole thing to a virtual disk image and run in using Parallels. What I had thought would only take an hour or two wound up being an entire weekend saga. But end the end I was victorious and the virtual server now runs like a champ on my Mac Mini. What follows are the steps and software tools that I used to make the migration.

Note: if you are using an Windows OS more recent than NT, you can use Parallels Transporter to easily convert an older server into a virtual machine. The technique below is much more labor, however will work on older Windows systems and, theoretically, any other OS. Also, I suspect these steps could be followed for use with another emulator such as VMWare or VirtualBox.

The first step of the process was to make a disk image of the drive. This actually can be done using a variety of GUI utilities if you can physically remove the drive and place it into another machine. In my case the two disk volumes were spread across 4 physical disks on an old Compaq RAID array. Not to mention they were old SCSI drives and I didn’t have the hardware to plug them into another machine anyway. What I did find was a nice little app called G4U (Ghost for Linux)

G4U basically did all of the hard work, but it didn’t quite get me all the way home. Following the G4U instructions I created a boot disk CD and booted the old hardward. G4U is a command-line utility with a command uploaddisk. This command basically converts the drive of your choosing to a raw image file and simultaneously uploads it to the FTP server of your choosing. I did this using a local FTP server and the result was a .gz file containing the raw disk image.

Now that I had the disk image the next step is to get the data out of that image and into a Parallels virtual machine. I created a Parallels virtual machine with a blank virtual drive the same size as the old server drive (actually I made it a little bigger to be safe). I then booted up this virtual machine as if I was going to install Windows, only I booted from the G4U boot disk. At the G4U prompt the command slurpdisk connects to an FTP server, decompresses the raw .gz image file to a physical drive. (In my case, I copied it to the new, blank virtual drive.)

Once this step was complete I had what should have been an exact copy of the drive from the hardware duplicated on a parallels .hdd drive file. And indeed I did have this; however, there was a problem – it wouldn’t boot! Apparently something with the old RAID controller or the conversion process had not correctly copied the boot sector. I could mount the disk image and see that all the data was there but Parallels would just not recognize the drive as being a bootable image.

I know there are ways to fix the boot sector using special fdisk options, however they tend to wipe out the data – which obviously wouldn’t work. There’s probably non-destructive ways as well. What I wound up doing, though, was to create a new Parallels machine with a new/blank drive and install on it a fresh copy of Windows NT. In other words, I basically created a regular virtual machine running Windows NT. (In hindsight I probably could have just copied any existing virtual machine that I had)

So at this point I had a) A virtual drive copy of the old hardware drive that was non-bootable and b) A clean NT virtual machine that was bootable. I needed to get the files from A onto B. I figured a straight copy using windows explorer would wipe out critical NTFS system data, but I couldn’t copy the whole partition either and lose the boot sector info. I located another free utility program called XXCOPY which promised to copy NTFS files as-is preserving all system meta-data. (Vista has a new feature called RoboCopy which may also work for this purpose.) I mounted both disk images on my main XP installation so I would work with the filesystems. I deleted all of the NT files from the clean install using Windows Explorer, thus I have a blank, but bootable drive. Then using XXCOPY I copied the old serer’s entire C drive contents to the blank, bootable drive.

To be honest, I wasn’t expecting this to work. The copy took a while, but after I was done I booted up from that drive and to my amazement it started! It took a lot of trial and error, but in the end the application was liberated from it’s old hardware and now runs happily on any decent computer with Parallels installed.

I started with various failed attempts to recover the password using boot disks that grab info from the SAM database and crack the passwords. Since this was older hardware with an old drive array configuration, though, several of these recovery disks couldn’t recognize the drive. One program did see the drive and recover the SAM information but was unable to crack the password.

I do think that strategy would have eventually worked. But, I decided it would be easier to re-set the password instead of recovering it. There is an old trick with NT and 2000 machines if you have physical access the the machine where you replace login.scr with cmd.exe.

First you boot from an NTFS boot disk. The NTFS boot disk above gives you a windows DOS prompt with full read/write access to the drives on the server, though you are not technically authenticated as a user on the system.  C:\winnt\system32\login.scr is the screensaver executable that Windows runs automatically at the login prompt. You can use this hack to fool Windows into opening up a DOS shell with system priviledges. At the boot disk command prompt enter the following to backup and replace login.scr with cmd.exe:


copy c:\winnt\system32\login.scr login.bak
copy c:\winnt\system32\cmd.exe login.scr


Now that login.scr was replaced, remove the boot disk and re-boot to the NT login prompt. I waited until Windows launched login.scr (default is 15 minutes) and a DOS command window opened right on top of the login prompt. The following DOS command changes the Administrator password:


net user Administrator mynewpass


The password is now changed. Finally, I gave the old Microsoft 3-finger salute (ctrl+alt+del) and logged on using the username/password I just created. Woot!

WARNING: If this is a domain controller or using active directory, I have read that this trick is not advisable and may cause you some file permission headaches.

With the latest version of Parallels coherence mode you can run Windows apps yet have the Windows OS itself transparent. This creates the visual effect that you are running Windows apps within OSX. The coherence feature is still a little rough but it got my gears spinning and I saw some amazing possibilities. The illusion doesn’t seem quite complete to me without being able to launch Windows apps from the Dock. I created this simple app as a proof of concept that it could be easily done. It’s simple but it works!

You can try it out for yourself: Download docksync_v01.zip

The app requires .NET Framework 2.0 which you can install from Windows Update

Update: Grab Matt’s add-on DockSyncOSX and you can drag/drop Windows Shortcuts!

Demo Video

How does it work?

Obviously there is some communication between OSX and Windows already through parallels. But, not having access to that API, I decided to create a simple app on the Windows side that basically monitors a shared directory. On the OSX side, you simply create a specially crafted text file in that directory to send a command over to Windows. Any OSX method to generate a text file can be used. Just to keep things simple, I used a shell script that can be executed by double-clicking an icon. The result is crude but it works and hopefully might inspire someone to take it a little further.

Here’s a screenshot of the Windows app that’s monitoring for commands:

This is being released with no license so use the code at your own risk. If you have any suggestions or updates, please post them here. In particular if you know of an cleaner way to trigger the creation of the task file on the OSX side, that would be cool. Preferably something that people can create and edit without having to compile.

Download docksync_v01.zip

Well I have seen the future. And it is not quite what I was expecting.

I’ve been playing around with the latest beta version of Parallels, which is now available for download from the parallels forums. There’s a surprising amount of new feature for a minor version update, but one that I found strange and interesting is a feature called “Coherence Mode.” Coherence mode is supposed to allow you to run windows applications right on the OSX desktop.

As you can see from the screenshot, it really does visually look like you are running a windows application right there on the desktop. Since you can drag your mouse around and grab various windows in either Windows or OSX, it really does somewhat feel like the apps are running in OSX too… kinda! What Parallels seems to have done is basically to have windows running over the top of OSX, but visually hide the actual desktop. So, it is more or less just a visual trick. One wierd thing that you’ll notice from the screenshot is that the windows taskbar is floating just above the OSX dock. I’m sure Apple fanboys will struggle to keep their lunch down at the sight of it! Even I find it a ugly.

In addition to the Coherence Mode feature, Parallels now supports drag-n-drop between the two operating systems. This feature works really great. Though it is again some amount of visual trickery again, since files could be easily copied through the virtual shared directories. You can’t drag a file from a windows app to a mac app – now that would be cool! But, it’s seamless and this is a really nice feature.

All in all, I think they are on the right track. If they can get the drag-n-drop working a little better when in coherence mode, perhaps even dragging and dropping between applications, that would really make it feel like the windows app is truly running in OSX.

UPDATE:. I am also told that following my instructions may or may not result in a healthy binary, although it seemed to work for me. (Thanks to Thomas Hruska and the openssl.org users list for the info)

[i:18d3bd8262]– original walkthrough (ie, the hard way) –

A. Requirements:

1. Visual C++ (which, unfortunately is not a free software) You can download nmake.exe by itself from [url]http://download.microsoft.com/download/vc15/Patch/1.52/W95/EN-US/Nmake15.exe[/url] however I am told that OpenSSL will only compile successfully if you have the full version of Visual C++.

2. ActiveState Perl. This can be downloaded freely from [url]http://www.activestate.com/[/url]

3. Some way of decompressing a tar.gz file. If you don’t already have anything, I recomment IZArc, which can be downloaded from [url]http://www.izsoft.dir.bg/izarc.htm[/url]. If you are familiar with unpacking tar.gz on unix, then you can use UNIX Utils (see below) instead.

4. UNIX Utils – obtained at [url]http://unxutils.sourceforge.net/[/url]. I don’t know for a fact that this is required, however I notice that compiles will many times fail because tar or gz or some other trivial unix command is not available. If you notice any such errors during compile, grab UNIX utils. If you do much compiling, just grab it anyway.

5. MASM assembler. Download it from [url]http://www.masm32.com/[/url] (this gets installed into your VC++ bin directory)

B. Preparation:

For VC++, if you didn’t elect to configure the command-line environment variables during installation, then you should run the batch file vcvars32.bat (which is in the VC++ directories somewhere) to set them.

MASM should include a bin directory and the contents are supposed to be installed into your VC++ bin directory as well. If you put them somewhere else, make sure this location is in your Path.

Make sure the path to Perl executable is in your Path.

Make sure the path to UNIX utils is in your Path. (I don’t know that this is absolutely necessary, but I have it set this way)

C. Installation

If everything is all set, installation should go as planned:

1. Download OpenSSL source from [url]http://www.openssl.org/[/url]. You will want to download the tar.gz that is marked as the “Latest” release.

2. Extract the tar.gz file using whatever method you like. Move this directory to “C:\OSSL” (this is an arbitrary location for the purposes of easy explaination)

3. Open a DOS window, move to the C:\OSSL directory, and execute the following commands: (These instructions are taken from install.w32 which is included in the OpenSSL install folder. I suggest you read it.)

> perl Configure VC-WIN32
> ms\do_masm
> nmake -f ms\ntdll.mak

If everything went ok, you’ll not see any error messages. If you do, the message should give some clue. Things like “ml not a valid command” etc indicate you don’t have your environmental paths set up correctly.

Now that OpenSSL is compiled, there are are some tests you can run to make sure it’s ok. Read install.w32 for info about these. Finally, you can move the necessary parts to their permenant home on your system. install.w32 recommends the following dos commands to do the trick (you can use windows explorer, though):

> md c:\openssl
> md c:\openssl\bin
> md c:\openssl\lib
> md c:\openssl\include
> md c:\openssl\include\openssl
> copy /b inc32\openssl\* c:\openssl\include\openssl
> copy /b out32dll\ssleay32.lib c:\openssl\lib
> copy /b out32dll\libeay32.lib c:\openssl\lib
> copy /b out32dll\ssleay32.dll c:\openssl\bin
> copy /b out32dll\libeay32.dll c:\openssl\bin
> copy /b out32dll\openssl.exe c:\openssl\bin

Open SSL should be compiled and available now.

In order to make the special folders visible, you have to remove the desktop.ini file inside Temporary Internet Files so that the folder is treated like a normal folder. Additionally, so that Windows does not auto-generate the file on the next reboot, you have to create a dummy desktop.ini file

The problem is that the files are hidden and marked as system files so they are not so simple to delete as you would think! You can do it, though, like so:

Open a DOS windows and navigate to C:\Documents and Settings\username\Local Settings\Temporary Internet Files

(username is replaced with your own username)

enter the following commands:

erase /as desktop.ini
echo [.ShellClassInfo] > desktop.ini

The first line deletes desktop.ini. the /as switch tells the erase command to delete the file even though it is marked as a system file. The echo line just creates another generic desktop.ini file. If this file is not present, Windows will auto-generate it on the next reboot and the folders will be hidden again.

Now browse Temporary Internet Files again. You’ll see some folders that were not previously visible. These are your cache files and you can poke around to find and/or delete files.

If you like, you can do the same with the History folder as well.